[xwiki-devs] [VOTE] Make Block navigation API a bit more generic
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block. interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE } [...] List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); } interface BlockMatcher { boolean match(Block block); } et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...). Note: the main use case for this change is to support MetaData search. WDYT (especially on the vocabulary like "TraversalStrategy") ? -- Thomas Mortagne
Nice API +1 Small suggestion : change CHILDRECURSE to CHILD_RECURSIVELY (same for previous and next of course). Jerome On Thu, Feb 10, 2011 at 6:27 PM, Thomas Mortagne <[email protected]>wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
XPath calls these "axes", http://www.w3.org/TR/xpath/#axes . We could stick to the same naming, since it's well known in the tree document model world. Otherwise I guess I agree with the change, although any generification and abstractization of the current already abstract model scares me. Thanks, Anca
On Thu, Feb 10, 2011 at 6:37 PM, Anca Luca <[email protected]> wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
XPath calls these "axes", http://www.w3.org/TR/xpath/#axes .
We could stick to the same naming, since it's well known in the tree document model world.
Ah yes, and "descendent" is better than "child-recurse" or "child-recursively". It's also a common naming in most DOM traversal APIs (prototype, etc.) Jerome.
Otherwise I guess I agree with the change, although any generification and abstractization of the current already abstract model scares me.
Thanks, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 02/10/2011 06:37 PM, Anca Luca wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
And in the same spirit of XPath:
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, to replace with DESCENDANT,
/** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE,
I'm not sure what this means exactly, but if there is an equivalent in the xPath axes, we could use it. In any case, to find a name with one word, if there's not, I'm gonna start doubting that we need it :) or that anyone but us will understand what it does. I think it might be the PRECEDING xpath axis, but I am not sure.
/** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE
same as in the previous case. We could add ANCESTOR.
}
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
XPath calls these "axes", http://www.w3.org/TR/xpath/#axes .
We could stick to the same naming, since it's well known in the tree document model world.
Otherwise I guess I agree with the change, although any generification and abstractization of the current already abstract model scares me.
Thanks, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Feb 10, 2011 at 18:44, Anca Luca <[email protected]> wrote:
On 02/10/2011 06:37 PM, Anca Luca wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
And in the same spirit of XPath:
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, to replace with DESCENDANT,
/** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE,
I'm not sure what this means exactly, but if there is an equivalent in
It means that you search something before you. A use case used in the toc is to search the HeaderBlock associated to the section in which the toc is located, the HeaderBlock could be a sibling of the toc macro itself or a sibling of one of the toc macro parents. It's almost the same thing than "preceding" in XPATH and except that it does not search in previous children. Not sure if i should change it to be XPATH "preceding" or have both (since "preceding" could potentially cost a lot more).
the xPath axes, we could use it. In any case, to find a name with one word, if there's not, I'm gonna start doubting that we need it :) or that anyone but us will understand what it does. I think it might be the PRECEDING xpath axis, but I am not sure.
/** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE
same as in the previous case.
We could add ANCESTOR.
Yes I plan to put all XPATH axis that make sense in XDOM.
}
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
XPath calls these "axes", http://www.w3.org/TR/xpath/#axes .
We could stick to the same naming, since it's well known in the tree document model world.
Otherwise I guess I agree with the change, although any generification and abstractization of the current already abstract model scares me.
Thanks, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Feb 10, 2011 at 18:37, Anca Luca <[email protected]> wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
XPath calls these "axes", http://www.w3.org/TR/xpath/#axes .
We could stick to the same naming, since it's well known in the tree document model world.
Indeed thanks for the reference, i did not know that.
Otherwise I guess I agree with the change, although any generification and abstractization of the current already abstract model scares me.
Thanks, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Feb 10, 2011, at 6:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
recurse param should be removed right?
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
same here
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Frenglish? ;) +1 Thanks -Vincent
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
-- Thomas Mortagne
On Thu, Feb 10, 2011 at 18:40, Vincent Massol <[email protected]> wrote:
On Feb 10, 2011, at 6:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
recurse param should be removed right?
Yep sorry several mixed versions.
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
same here
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Frenglish? ;)
oups "and we refactor all the other get*Block based on these new methods using predifined BlockMatcher (ClassBlockMatcher, MetaDataBlockMatcher, etc...)"
+1
Thanks -Vincent
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
-- Thomas Mortagne
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 02/10/2011 07:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
Have you considered replacing get...Block methods with Block iterators? Iterator<Block> iterator = new MetaDataIterator(new ChildrenIterator(parent)); Hope this helps, Marius
On Fri, Feb 11, 2011 at 00:10, Marius Dumitru Florea <[email protected]> wrote:
On 02/10/2011 07:27 PM, Thomas Mortagne wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
Have you considered replacing get...Block methods with Block iterators?
Yep, the most generic method is not method ;) Thing is I don't have the time to define and validate something that is a whole new concept so I'm proposing what I have the time to do but still let me sleep at night :)
Iterator<Block> iterator = new MetaDataIterator(new ChildrenIterator(parent));
Hope this helps, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Feb 10, 2011 at 6:27 PM, Thomas Mortagne <[email protected]> wrote:
Here is a proposal to reduce all get...Block to 2 methods which support matching any Block.
interface Block { enum TraversalStrategy { /** Search in parents **/ PARENT, /** Search in children **/ CHILD, /** Search recursively in children (and children of children etc...) **/ CHILDRECURSE, /** Search in previous siblings **/ PREVIOUS, /** Search recursively in previous siblings (and parent previous sibling etc...) **/ PREVIOUSRECURSE, /** Search in next siblings**/ NEXT, /** Search recursively in next siblings (and children etc...)**/ NEXTRECURSE }
[...]
Why instead of using the *RECURSE constants you don't put an "int depth" parameter in the get* methods signature? This would capture the recursive behavior for every TraversalStrategy. DEPTH_INFINITY could be a constant for visiting the elements in the whole tree. -Fabio
List<Block> getBlocks(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse);
Block getFirstBlock(BlockMatcher matcher, TraversalStrategy traversalStrategy, boolean recurse); }
interface BlockMatcher { boolean match(Block block); }
et on refactor tous les autres get*Block basé sur ceux la avec des BlockMatcher prédéfinis (ClassBlockMatcher, MetaDataBlockMatcher, etc...).
Note: the main use case for this change is to support MetaData search.
WDYT (especially on the vocabulary like "TraversalStrategy") ?
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Anca Luca -
Fabio Mancinelli -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol