10 Feb
2011
10 Feb
'11
6:27 p.m.
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
10 Feb
10 Feb
6:33 p.m.
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
<thomas.mortagne(a)xwiki.com>wrote;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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:37 p.m.
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
6:41 p.m.
On Thu, Feb 10, 2011 at 6:37 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:44 p.m.
On 02/10/2011 06:37 PM, Anca Luca wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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.
>
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
6:55 p.m.
On Thu, Feb 10, 2011 at 18:44, Anca Luca <lucaa(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On 02/10/2011 06:37 PM, Anca Luca wrote:
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).
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.
Yes I plan to put all XPATH axis that make sense in XDOM.
> /** 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
6:45 p.m.
On Thu, Feb 10, 2011 at 18:37, Anca Luca <lucaa(a)xwiki.com> wrote:
On 02/10/2011 06:27 PM, Thomas Mortagne wrote:
Indeed thanks for the reference, i did not know that.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
6:40 p.m.
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
6:43 p.m.
On Thu, Feb 10, 2011 at 18:40, Vincent Massol <vincent(a)massol.net> wrote:
oups
"and we refactor all the other get*Block based on these new methods
using predifined BlockMatcher (ClassBlockMatcher,
MetaDataBlockMatcher, etc...)"
On Feb 10, 2011, at 6:27 PM, Thomas Mortagne wrote:
Yep sorry several mixed versions.
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
--
Thomas Mortagne
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 Feb
11 Feb
12:10 a.m.
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
16 Feb
16 Feb
5:06 p.m.
On Fri, Feb 11, 2011 at 00:10, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On 02/10/2011 07:27 PM, Thomas Mortagne wrote:
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 :)
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11 Feb
11 Feb
12:30 p.m.
On Thu, Feb 10, 2011 at 6:27 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4961
days inactive
4967
days old
11 comments
6 participants
participants (6)
-
Anca Luca -
Fabio Mancinelli -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol