[xwiki-devs] [VOTE] Introduce BlockCollection Block wrapper
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
On Fri, 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 ?
+1, obviously :)
Any better idea for the name ?
BlockCollection sounds good. Thanks, JV.
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/
On Fri, Sep 28, 2012 at 10:11 PM, Sergiu Dumitriu <[email protected]> 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 the idea is to be able to pass or return several Block as a single Block, BlockCollection would extend Block.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Sep 28, 2012 at 11:11 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Sep 28, 2012 at 10:11 PM, Sergiu Dumitriu <[email protected]> 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.
I OK with BlockList since it's actually more a List than a Collection.
Here is my +1.
+0. -- Sergiu Dumitriu http://purl.org/net/sergiu/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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
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
On Oct 1, 2012, at 11:16 AM, Vincent Massol <[email protected]> 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 <[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
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol <[email protected]> wrote:
On Oct 1, 2012, at 11:16 AM, Vincent Massol <[email protected]> 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.
I'm OK with CompositeBlock. I don't have much more argument than "BlockList sounds nicer" so for now you win.
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 <[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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, Oct 1, 2012 at 11:36 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol <[email protected]> wrote:
On Oct 1, 2012, at 11:16 AM, Vincent Massol <[email protected]> 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.
I'm OK with CompositeBlock.
I don't have much more argument than "BlockList sounds nicer" so for now you win.
I think CompositeBlock sounds even better. JV.
On Mon, Oct 1, 2012 at 12:56 PM, Jean-Vincent Drean <[email protected]> wrote:
On Mon, Oct 1, 2012 at 11:36 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Oct 1, 2012 at 11:23 AM, Vincent Massol <[email protected]> wrote:
On Oct 1, 2012, at 11:16 AM, Vincent Massol <[email protected]> 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.
I'm OK with CompositeBlock.
I don't have much more argument than "BlockList sounds nicer" so for now you win.
I think CompositeBlock sounds even better.
+1 Thanks, Marius
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
4 +1 and one +0 for BlockList, doing it now On Fri, 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.
-- Thomas Mortagne
-- Thomas Mortagne
Actually moved to CompositeBlock after new votes. On Mon, Oct 1, 2012 at 11:07 AM, Thomas Mortagne <[email protected]> wrote:
4 +1 and one +0 for BlockList, doing it now
On Fri, 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.
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
participants (5)
-
Jean-Vincent Drean -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol