You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/01/01 18:39:20 UTC

Re: Problems with writing sitemap components as spring beans

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

HTH
Carsten

-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Problems with writing sitemap components as spring beans

Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> 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"/>
>   </util:map>
> 
>   <bean name="org.apache.cocoon.serialization.Serializer/xml" 
> class="org.apache.cocoon.serialization.XMLSerializer"
>         scope="prototype" 
> parent="org.apache.cocoon.serialization.AbstractTextSerializer"/>
> 
> 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"
>             
> class="org.apache.cocoon.core.apropriate_sub_package.ProcessorComponentInfoBeanFactory">
>     <property name="mimeType" value="text/xml"/>
>     <property name="label" value="output"/>
>    </bean/>
> 
> 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.
> 
I think the first solution is the a little bit easier to implement and
does not require to much coding in xml for the configuration, so I think
we should go for the first solution.

If anyone has time to imlement it, we could think about adding our own
tags for this configuration, so this could look like this:
<bean name="org.apache.cocoon.serialization.Serializer/xml"
 class="org.apache.cocoon.serialization.XMLSerializer"
         scope="prototype">
  <namespace:sitemap-component label="gg" mime-type="..."/>

This shouldn't be too hard.

> 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.
Yes, it would be good if we could move this stuff out of the current
avalon bridge!

Carsten

-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Problems with writing sitemap components as spring beans

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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"/>
  </util:map>

  <bean name="org.apache.cocoon.serialization.Serializer/xml" 
class="org.apache.cocoon.serialization.XMLSerializer"
        scope="prototype" 
parent="org.apache.cocoon.serialization.AbstractTextSerializer"/>

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"
            
class="org.apache.cocoon.core.apropriate_sub_package.ProcessorComponentInfoBeanFactory">
    <property name="mimeType" value="text/xml"/>
    <property name="label" value="output"/>
   </bean/>

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.

WDYT?

/Daniel