20 Feb
2011
20 Feb
'11
2:34 p.m.
On Feb 20, 2011, at 2:14 PM, Thomas Mortagne wrote:
On Sun, Feb 20, 2011 at 14:05, Vincent Massol
<vincent(a)massol.net> wrote:
Yes Marius asked about this and I had the same use case in the Include macro where
I've had to clone the XDOM so that applying transformations do not modify the original
XDOM.
(Another idea related to this is to implement our original block solution we talked about
for implementing generic markers and so that on a given XDOM you could call:
XDOM.getOriginalXDOM(), revertChanges() and the like.)
Thanks
-Vincent
On Feb 20, 2011, at 1:41 PM, Thomas Mortagne wrote:
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). On Sun, Feb 20, 2011 at 12:56, Vincent Massol
<vincent(a)massol.net> wrote:
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).
On Feb 20, 2011, at 12:30 PM, Thomas Mortagne wrote:
> On Sun, Feb 20, 2011 at 09:52, Vincent Massol <vincent(a)massol.net> 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. > 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