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 <[email protected]> wrote:
On Sep 28, 2012, at 11:54 AM, Thomas Mortagne <[email protected]> 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