cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon 2.2 ... )
Date Mon, 10 Nov 2003 11:22:32 GMT


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: maandag 10 november 2003 12:16
> To: dev@cocoon.apache.org
> 
> 
> On 9 Nov 2003, at 21:57, Unico Hommes wrote:
> 
> >
> >
> >

<snip/>

> >> 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.
> >
> > 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" />
> > </pipeline>
> > <match id="m1" pattern="...">
> >   ...
> > </match>
> >
> > 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 configuration.
> >
> > 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:
> >
> > <sitemap>
> >   <components>
> >     <generators>
> >       <generator name="file" />
> >   ...
> >   <pipelines>
> >     ...
> >     <generate type="file" />
> >
> > becomes:
> >
> > <sitemap>
> >   <generator id="file-generator" />
> >   ...
> >   <generate ref-id="file-generator" />
> >   ...
> > </sitemap>
> >
> >
> > WDYT?
> 
> I agree with your vision. The sitemap describes things and uses them
in
> a sort of id/idref pairing but in different ways, depending of the
> place (this was done to allow the sitemap to feel less programmable
and
> more "usable").
> 
> Now, what I don't get is what you're tring to do with this. I hope you
> are not implying that we change the sitemap syntax in order to be more
> fortress friendly, are you?
> 

Nope ;-) Sorry I wasn't clear on this. I meant this as an implementation
for the TreeProcessor where the sitemap is a virtual configuration that
is translated at runtime into a form more palatable by Fortress.

Unico

> --
> Stefano.
> 



Mime
View raw message