On Sun, Feb 20, 2011 at 14:05, Vincent Massol <[email protected]> wrote: > > On Feb 20, 2011, at 1:41 PM, Thomas Mortagne wrote: > >> On Sun, Feb 20, 2011 at 12:56, Vincent Massol <[email protected]> wrote: >>> >>> On Feb 20, 2011, at 12:30 PM, Thomas Mortagne wrote: >>> >>>> On Sun, Feb 20, 2011 at 09:52, Vincent Massol <[email protected]> wrote: >>>>> Hi Thomas, >>>>> >>>>> I think it could be a good idea to remove (deprecate?) the current >>>>> BlockFilter interface/implementations and instead use the newly >>>>> introduced BlockMatcher. WDYT? >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>> >>>> It's not exactly the same thing. BlockFilter is used to modify the >>>> tree and can produce new blocks that did not existed (like generating >>>> a label for a standalone link for example). Impossible to replace it >>>> with BlockMatcher as it is. >>> >>> hmmm ok. I was looking at PlainTextBlockFilter which at least could be >>> replaced with a PlainTextBlockMatcher. Seems we're using BlockFilter for >>> clone() and I thought it would be better to have clone(BlockMatcher). >> >> Actually no, the link example I just described is used in >> PlainTextBlockFilter. >> >>> >>> Shouldn't we use transformations for modifying an input Block (or XDOM) >>> into another output Block (XDOM)? >> >> When you write a transformation you have to to the tree parsing, here >> the goal was to provide something easy where you just need to >> implements BlockFilter. > > Indeed it's just that we have 3 notions that seem very close: BlockMatcher, > BlockFilter and Transformation. I thought maybe it was a bit too much and it > could be simpler for users to simplify the API. > > We could have a tree iterator that could be used in transformations to > traverse the tree for example (actually we discussed about this together in > the paste since several transformations we currently have duplicate the tree > traversal code).
Sure, thing is BlockFilter is kind of feature driven development and I did not though much about it: I needed to convert a XDOM to its plain text version. Problem is that cloning plus executing transformation cost a lot more since you clone the whole tree (even if you don't need to) then you reparse it to transform it. But we could maybe extends transformations to have the two concepts (cloning or modifying directly). > > Also maybe BlockFilter terminology isn't the best if it's not just about > filtering but also about generating tree nodes. > > I don't have a solution ATM so I'll stop this thread here but we might want > to think about this for the future, possibly look at how it's done in other > tree solutions (XML DOM, JCR, etc). > > Thanks > -Vincent > > _______________________________________________ > 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
