10 Feb
2011
10 Feb
'11
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