1 Oct
2012
1 Oct
'12
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