28 Sep
2012
28 Sep
'12
11:54 a.m.
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
--
Thomas Mortagne
28 Sep
28 Sep
12:23 p.m.
On Fri, Sep 28, 2012 at 11:54 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
+1, obviously :)
Any better idea for the name ?
BlockCollection sounds good.
Thanks,
JV.
10:11 p.m.
On 09/28/2012 05:54 AM, Thomas Mortagne wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Does BlockCollection extend Block or the other way around? It's not very
clear to me how exactly this would work.
Since UI extension is going to use it a lot I propose
to introduce it now.
WDYT ?
Any better idea for the name ?
In standard DOM that's a NodeList, so BlockList would be the equivalent
name.
Here is my +1.
+0.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
30 Sep
30 Sep
10:36 a.m.
On Fri, Sep 28, 2012 at 10:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 09/28/2012 05:54 AM, Thomas Mortagne wrote:
Since the idea is to be able to pass or return several Block as a
single Block, BlockCollection would extend Block.
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Does BlockCollection extend Block or the other way around? It's not very
clear to me how exactly this would work. Since UI extension is going to use it a lot I
propose to introduce it now.
WDYT ?
Any better idea for the name ?
In standard DOM that's a NodeList, so BlockList would be the equivalent
name.
Here is my +1.
+0.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
1 Oct
1 Oct
8:19 a.m.
On Fri, Sep 28, 2012 at 11:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 09/28/2012 05:54 AM, Thomas Mortagne wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Does BlockCollection extend Block or the other way around? It's not very
clear to me how exactly this would work.
Since UI extension is going to use it a lot I
propose to introduce it now.
WDYT ?
Any better idea for the name ?
In standard DOM that's a NodeList, so BlockList
would be the equivalent
name.
If the order of the blocks matters (most of the time) then I'm in
favour of BlockList too.
Thanks,
Marius
Here is my +1.
+0.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:44 a.m.
On Fri, Sep 28, 2012 at 10:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 09/28/2012 05:54 AM, Thomas Mortagne wrote:
I OK with BlockList since it's actually more a List than a Collection.
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Does BlockCollection extend Block or the other way around? It's not very
clear to me how exactly this would work.
Since UI extension is going to use it a lot I
propose to introduce it now.
WDYT ?
Any better idea for the name ?
In standard DOM that's a NodeList, so BlockList would be the equivalent
name. Here is my +1.
+0.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
9:18 a.m.
On Sep 28, 2012, at 11:54 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
I'm +1 with the idea.
I'm ok with BlockList (hoping that people will not confuse BlockList with ListBlock
;)).
Another possibility is to use a name that reflects what it is, i.e. a composite pattern
(see http://en.wikipedia.org/wiki/Composite_pattern) and call it: CompositeBlock
I'm also ok for that since we've used that naming in several other places.
So to summarize:
+0 BlockCollection
+1 ListBlock
+1 CompositeBlock
Thanks
-Vincent
11:16 a.m.
I'm changing my vote to -0 for BlockList FTM since I've just realized there might
a problem.
BlockList means that it's a list of block. But this is not what it is…
It's a Block like any other block. The important part is not that it's a list of
blocks, all our blocks are list of blocks.
The important part is that it can be used to hold one or several blocks.
-Vincent
On Oct 1, 2012, at 9:18 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Sep 28, 2012, at 11:54 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
I'm +1 with the idea.
I'm ok with BlockList (hoping that people will not confuse BlockList with ListBlock
;)).
Another possibility is to use a name that reflects what it is, i.e. a composite pattern
(see http://en.wikipedia.org/wiki/Composite_pattern) and call it: CompositeBlock
I'm also ok for that since we've used that naming in several other places.
So to summarize:
+0 BlockCollection
+1 ListBlock
+1 CompositeBlock
Thanks
-Vincent
11:23 a.m.
On Oct 1, 2012, at 11:16 AM, Vincent Massol <vincent(a)massol.net> wrote:
I'm changing my vote to -0 for BlockList FTM since
I've just realized there might a problem.
BlockList means that it's a list of block. But this is not what it is…
It's a Block like any other block. The important part is not that it's a list of
blocks, all our blocks are list of blocks.
The important part is that it can be used to hold one or several blocks.
More precisely, compared to the other existing block this is a type of block that add no
additional metadata.
It's a no op block basically.
The fact that it's a list of Block is a feature of all blocks so this one doesn't
need to mention that explicitly I think.
ATM I prefer CompositeBlock than BlockList which I find a bit misleading.
NoOpBlock would be ok too I guess but I don't like it too much.
I'm very close to -1 for BlockList.
Since it's a block its name must end by Block and the prefix should qualify the type
of block it is.
Thanks
-Vincent
PS: NodeList doesn't implement Node.
-Vincent
On Oct 1, 2012, at 9:18 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Sep 28, 2012, at 11:54 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
I'm +1 with the idea.
I'm ok with BlockList (hoping that people will not confuse BlockList with ListBlock
;)).
Another possibility is to use a name that reflects what it is, i.e. a composite pattern
(see http://en.wikipedia.org/wiki/Composite_pattern) and call it: CompositeBlock
I'm also ok for that since we've used that naming in several other places.
So to summarize:
+0 BlockCollection
+1 ListBlock
+1 CompositeBlock
Thanks
-Vincent
11:36 a.m.
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Oct 1, 2012, at 11:16 AM, Vincent Massol <vincent(a)massol.net> wrote:
I'm OK with CompositeBlock.
I don't have much more argument than "BlockList sounds nicer" so for
now you win.
I'm changing my vote to -0 for BlockList FTM
since I've just realized there might a problem.
BlockList means that it's a list of block. But this is not what it is…
It's a Block like any other block. The important part is not that it's a list of
blocks, all our blocks are list of blocks.
The important part is that it can be used to hold one or several blocks.
More precisely, compared to the other existing block this is a type of block that add no
additional metadata.
It's a no op block basically.
The fact that it's a list of Block is a feature of all blocks so this one doesn't
need to mention that explicitly I think.
ATM I prefer CompositeBlock than BlockList which I find a bit misleading.
NoOpBlock would be ok too I guess but I don't like it too much.
I'm very close to -1 for BlockList.
Since it's a block its name must end by Block and the prefix should qualify the type
of block it is.
Thanks
-Vincent
PS: NodeList doesn't implement Node.
--
Thomas Mortagne
-Vincent
On Oct 1, 2012, at 9:18 AM, Vincent Massol <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Sep 28, 2012, at 11:54 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
I'm +1 with the idea.
I'm ok with BlockList (hoping that people will not confuse BlockList with ListBlock
;)).
Another possibility is to use a name that reflects what it is, i.e. a composite pattern
(see http://en.wikipedia.org/wiki/Composite_pattern) and call it: CompositeBlock
I'm also ok for that since we've used that naming in several other places.
So to summarize:
+0 BlockCollection
+1 ListBlock
+1 CompositeBlock
Thanks
-Vincent
11:56 a.m.
On Mon, Oct 1, 2012 at 11:36 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol
<vincent(a)massol.net> wrote:
I think CompositeBlock sounds even better.
JV.
On Oct 1, 2012, at 11:16 AM, Vincent Massol <vincent(a)massol.net> wrote:
I'm OK with CompositeBlock.
I don't have much more argument than "BlockList sounds nicer" so for
now you win.
I'm changing my vote to -0 for BlockList FTM
since I've just realized there might a problem.
BlockList means that it's a list of block. But this is not what it is…
It's a Block like any other block. The important part is not that it's a list of
blocks, all our blocks are list of blocks.
The important part is that it can be used to hold one or several blocks.
More precisely, compared to the other existing block this is a type of block that add no
additional metadata.
It's a no op block basically.
The fact that it's a list of Block is a feature of all blocks so this one doesn't
need to mention that explicitly I think.
ATM I prefer CompositeBlock than BlockList which I find a bit misleading.
NoOpBlock would be ok too I guess but I don't like it too much.
I'm very close to -1 for BlockList.
12:06 p.m.
On Mon, Oct 1, 2012 at 12:56 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
On Mon, Oct 1, 2012 at 11:36 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol
<vincent(a)massol.net> wrote:
On Oct 1, 2012, at 11:16 AM, Vincent Massol <vincent(a)massol.net> wrote:
I'm OK with CompositeBlock.
I don't have much more argument than "BlockList sounds nicer" so for
now you win.
I'm changing my vote to -0 for BlockList FTM
since I've just realized there might a problem.
BlockList means that it's a list of block. But this is not what it is…
It's a Block like any other block. The important part is not that it's a list of
blocks, all our blocks are list of blocks.
The important part is that it can be used to hold one or several blocks.
More precisely, compared to the other existing block this is a type of block that add no
additional metadata.
It's a no op block basically.
The fact that it's a list of Block is a feature of all blocks so this one doesn't
need to mention that explicitly I think.
ATM I prefer CompositeBlock than BlockList which I find a bit misleading.
NoOpBlock would be ok too I guess but I don't like it too much.
I'm very close to -1 for BlockList. I think CompositeBlock sounds even better.
+1
Thanks,
Marius
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:07 a.m.
4 +1 and one +0 for BlockList, doing it now
On Fri, Sep 28, 2012 at 11:54 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
--
Thomas Mortagne
--
Thomas Mortagne
12:23 p.m.
Actually moved to CompositeBlock after new votes.
On Mon, Oct 1, 2012 at 11:07 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
4 +1 and one +0 for BlockList, doing it now
On Fri, Sep 28, 2012 at 11:54 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
--
Thomas Mortagne
--
Thomas Mortagne
4368
days inactive
4371
days old
13 comments
5 participants
participants (5)
-
Jean-Vincent Drean -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol