Adding DOM tree support to Doxia?

[Vincent Massol <vi...@massol.net>]

Hi,

While it's nice that Doxia supports stream-parsing, there are valid  
use cases for generating a DOM tree of source elements (the Blocks  
that can be found in the confluence and twiki parser implementations  
for example).

Since the confluence and twiki parsers already need these blocks, and  
since I need them too for the XWiki parser I think there's already a  
valid use case for them.

In addition, I would add the method to return this DOM tree to the  
Parser class in doxia-core (or add 2 interfaces, one for stream  
parsers and one for DOM parsers).

WDYT?

Note: In XWiki land we need to parse all pages into a DOM tree for  
performance reasons: we'll cache the DOM tree so that the rendering  
can be done faster.

Thanks
-Vincent

Re: Adding DOM tree support to Doxia?

[Jason van Zyl <ja...@maven.org>]

On 31 Dec 07, at 5:02 AM 31 Dec 07, Vincent Massol wrote:

> Hi,
>
> While it's nice that Doxia supports stream-parsing, there are valid  
> use cases for generating a DOM tree of source elements (the Blocks  
> that can be found in the confluence and twiki parser implementations  
> for example).
>

If you look at the StructureSink it's basically an in-memory model  
that can replay events. But it would be easy enough to make a DOMSink  
easy enough. Then you could read it like a DOM or play the events back.

> Since the confluence and twiki parsers already need these blocks,  
> and since I need them too for the XWiki parser I think there's  
> already a valid use case for them.
>

I definitely think it's useful.

> In addition, I would add the method to return this DOM tree to the  
> Parser class in doxia-core (or add 2 interfaces, one for stream  
> parsers and one for DOM parsers).
>

As long as this is done lazily upon request and not done all the time.

> WDYT?
>
> Note: In XWiki land we need to parse all pages into a DOM tree for  
> performance reasons: we'll cache the DOM tree so that the rendering  
> can be done faster.
>

Sure, I think that's what was originally done with the StructureSink  
and completely valid. I'm sure you we could come up with a super  
efficient, pre-digested structure that tracked macros and any other  
bits.

I say prototype away on a branch, or if it's all additions to the API  
then just do it on trunk.

> Thanks
> -Vincent

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

We all have problems. How we deal with them is a measure of our worth.

-- Unknown