cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon 2.2 ... )
Date Sun, 09 Nov 2003 20:57:23 GMT

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:

   <match pattern="...">

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.

This means that from a container POV the sitemap is a more human 
readable view on the 'actual' container configuration which looks more like:

<pipeline id="p1">
   <childnode id-ref="m1" />
<match id="m1" pattern="...">

Where the 'childnode' element now is a proper configuration element and 
match is a proper component declaration. Sitemap container configuration 
is then a transformation of the sitemap to a default container 

ParentProcessingNodes obtain their children by reading the reference 
id's to their child nodes during configuration phase and a simple lookup 
on the service manager during the service phase.

I think we can use this approach nicely with view and resource lookups 
and sitemap component lookups as well:

       <generator name="file" />
     <generate type="file" />


   <generator id="file-generator" />
   <generate ref-id="file-generator" />



View raw message