cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Problems with writing sitemap components as spring beans
Date Thu, 04 Jan 2007 10:58:35 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Carsten Ziegeler skrev:
>>> I think this is possible by creating a proxy around the generator with
>>> the special sitemap support.
>> Seem like a good solution.
>> I've tried to find out how label handling for sitemap components is 
>> solved now. But didn't found where in the code it is done, can you give 
>> me a pointer?
> The avalon bridge provides a ProcessorComponentInfo for the tree
> processor. This bean is created in the AvalonElementParser in the
> registerComponentInfo method. It loops through all registered components
> and gets the label etc. configuration from the sitemap components and
> registers them in the processor component info bean.
> The tree processor looks up the ProcessorComponentInfo bean and provides
> the informationen to the various parts in the tree processor
Thanks for the info.

After having looked at I think that the simplest solution would be to 
just provide one (singleton) info bean for each component. Something like:

  <util:map name="org.apache.cocoon.serialization.Serializer/xml/info">
    <entry key="mime-type" value="text/xml"/>
    <entry key="label" value="output"/>

  <bean name="org.apache.cocoon.serialization.Serializer/xml" 

Then the ProcessorComponentInfo can just look up the info from the 
container using <ComponentType>.ROLE/<hint>/info as key.

If it is better to store the info in the ProcessorComponentInfo, we 
could have a bean factory that looks up the ProcessorComponentInfo (or 
create it if needed), and store the info there instead:

  <bean name="org.apache.cocoon.serialization.Serializer/xml/info"
    <property name="mimeType" value="text/xml"/>
    <property name="label" value="output"/>

In this case the bean name is parsed for finding out what sitemap the 
component info is about. We could combine any of the above solutions 
with a custom xml format if we like to get a "prettier"notation.

Whatever solution we use, the mechanism for being able to store the info 
must be part of the pipeline layer, so that we can configure the 
pipeline components there.



View raw message