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

Reply via email to