20 Feb
2011
20 Feb
'11
9:52 a.m.
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
20 Feb
20 Feb
12:30 p.m.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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.
--
Thomas Mortagne
12:56 p.m.
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:
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).
Shouldn't we use transformations for modifying an input Block (or XDOM) into another
output Block (XDOM)?
Thanks
-Vincent
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.
1:41 p.m.
On Sun, Feb 20, 2011 at 12:56, Vincent Massol <vincent(a)massol.net> wrote:
On Feb 20, 2011, at 12:30 PM, Thomas Mortagne wrote:
Actually no, the link example I just described is used in PlainTextBlockFilter.
On Sun, Feb 20, 2011 at 09:52, Vincent Massol
<vincent(a)massol.net> wrote:
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). 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.
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.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
2:05 p.m.
On Feb 20, 2011, at 1:41 PM, Thomas Mortagne wrote:
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).
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
On Feb 20, 2011, at 12:30 PM, Thomas Mortagne wrote:
Actually no, the link example I just described is used in PlainTextBlockFilter.
On Sun, Feb 20, 2011 at 09:52, Vincent Massol
<vincent(a)massol.net> wrote:
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). 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.
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.
2:14 p.m.
On Sun, Feb 20, 2011 at 14:05, Vincent Massol <vincent(a)massol.net> wrote:
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:
Actually no, the link example I just described is used in PlainTextBlockFilter.
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).
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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
4957
days inactive
4957
days old
6 comments
2 participants
participants (2)
-
Thomas Mortagne -
Vincent Massol