Re: Migrating TreeProcessor to Fortress

[Sylvain Wallez <sy...@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.

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.

Or did I miss something?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com