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
Date Mon, 10 Nov 2003 16:17:14 GMT
 

> 
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: maandag 10 november 2003 16:44
> To: dev@cocoon.apache.org
> 
> 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.
> 

Off course this is not what I meant. I am talking about hosting
ProcessingNodes as components in Fortress.

> 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.
> 

Do you really think so? Off course there is some overhead associated
with hosting an object as a component. But today all statements are also
represented by it's own 'pseudo' component no? In fact it's very similar
to what we have today except for that all the component management will
be taken care of by Fortress. As far as I know a component in Fortress
is represented by the component instance itself and its handler. In the
case of singleton components - wich is what all ProcessingNode
components would be - the handler is a *very* lightweight object
wrapping the instance.

Unico


Mime
View raw message