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