cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Migrating TreeProcessor to Fortress
Date Mon, 10 Nov 2003 15:44:18 GMT
Unico Hommes wrote:

> Sylvain Wallez wrote:
>> Ryan Hoegg wrote:
>>> peter royal wrote:
>>>> Anyone:
>>>> Any thoughts about using Jelly as the builder for the sitemap?
>>>> Its usage can be completely hidden, but as a tag processor, it 
>>>> might work very well. We could use it to construct a bean-graph to 
>>>> model the sitemap.
>>>> -pete
>>> Sounds sensible.  Is jelly in use anywhere else in Cocoon?  It 
>>> sounds like a great fit.
>> Jelly is not currently used in Cocoon. The idea is interesting, but 
>> it also means a rewrite of a large part of the sitemap engine, and 
>> doesn't give an immediate answer to the mixing between components and 
>> container outlined by Berin.
>> Note that I don't state this to protect the current treeprocessor, 
>> but to minimize the work required to move to Fortress. Now I 
>> recognize I don't know Jelly and thus how hard this would be.
> I agree with this. Tonight I have been looking at the treeprocessor 
> code and think it would be quite straightforward to move things to 
> Fortress if we hold on to the idea of nodes as components. Proper 
> components that is, as opposed to what has been previously dubbed 
> 'pseudo components'. For this ProcessingNode and ProcessingNodeBuilder 
> should be merged.
> The only thing that was not immediately clear to me was how to build 
> the component graph structure. It seems that from a container POV the 
> sitemap node elements perform two seperate functions.
> Consider the following snippet:
> <pipeline>
>   <match pattern="...">
>     ...
>   </match>
> </pipeline>
> Here the match element both represents a component declaration of a 
> MatchNode to the container _and_ a configuration element representing 
> a child node to the PipelineNode.

Nope: the component declaration is in the <map:matcher> declaration in 
the <map:components> section. This is where its class, configuration and 
all the component declaration stuff is.

A <map:match> is a _use_ of that component. Sure, it can be transformed 
in a component declaration by merging in the configuration that's in 
<map:components> for each use of a particular component, but you'll end 
up with as many different independent components as there are sitemap 
_statements_, which will be a huge memory eater.

Or did I miss something?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message