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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
