cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon 2.2 ... )
Date Mon, 10 Nov 2003 11:16:19 GMT

On 9 Nov 2003, at 21:57, 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.
>
> 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?

--
Stefano.


Mime
View raw message