> -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: maandag 10 november 2003 12:16 > To: [EMAIL PROTECTED] > > > 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. >
