cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Overloaded pipeline elements (Was Re: [RT] FOM)
Date Wed, 28 May 2003 10:51:45 GMT

Christian Haul wrote:
> On 28.May.2003 -- 09:25 AM, Nicola Ken Barozzi wrote:
>>Marc Portier wrote, On 28/05/2003 8.38:
>>>Miles Elam wrote:
>>>>What is the purpose of resources if this new syntax goes into effect 
>>>>(which I like by the way)?  What can a resource do that an overloaded 
>>>>pipeline element cannot?
>>>I think as Stefano said (slightly rephrased): it would deprecate the use 
>>>of resources that are only fragments of pipelines.
>>Then we are basically killing resources, as complete pipelines can 
>>already be used instead of resources.
>>>Is this more then an issue of naming this concept? 
>>I mean, if we make use of resources as callable full or partial sitemap 
>>snippets, what would we loose that we instead get from using this new 
> What I would envision here is that these pipeline fragments are on par
> with ordinary sitemap components. We had this discussion before (a
> long long time ago) but then it didn't gain much interest. Looks like
> the time has come :-)
> If we look at it, there is no reason why something that exhibits the
> properties of say a transformer, that is, being a XMLConsumer and a
> XMLProducer, be treated differently from a monolithic transformer.
> So one would use (a subclass of) the TreeProcessor to build new Avalon
> components from pipeline fragments. Condition is, the aggregate
> exhibits the same interface as the other components in this group:
> Generator, Transformer, Serializer, Reader. 
> The current Resource == Serializer (i.e. XMLConsumer + SitemapOutputComponent).
> The "new" Resource == Reader (i.e. SitemapOutputComponent)
> Well then, no need to keep it ;-)
> If we are talking blocks, these pipelines behave like ordinary Avalon
> components and we don't need to worry about how to make them available
> to other blocks as this would be the same.
> However, these fragments need to allow all (most of?) the sitemap
> constructs IMO : e.g. chosing the right transformation step for a
> client browser makes perfect sense to put into such a fragment.
> What I see is for instance
>   <map:transformers>
>     <map:transformer logger="sitemap.transformer.encodeURL" 
>                      name="encodeURL" 
>                      src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
>     <map:transformer logger="sitemap.transformer.browser"
>                      name="renderForBrowser"
>                      src="org.apache.cocoon.components.treeprocessor.sitemap.TransformerNodeBuilder">
>         <map:select type="browser">
>     		<map:when test="netscape">
>     		   <map:transform src="stylesheets/{foo}/netscape.xsl" />
>     		</map:when>
>     		<map:when test="explorer">
>     		   <map:transform src="stylesheets/{foo}/ie.xsl" />
>     		</map:when>
>     		<map:when test="lynx">
>     		   <map:transform src="stylesheets/{foo}/text-based.xsl" />
>     		</map:when>
>     		<map:otherwise>
>     		   <map:transform src="stylesheets/{foo}/html.xsl" />
>     		</map:otherwise>
>         </map:select>
>     </map:transformer>
>   </map:transformers>
>   <map:pipelines>
>      <map:pipeline>
>         <map:match pattern="*">
>            <map:generate type="file" src="{1}"/>
>            <map:transform type="browser">
>               <map:parameter name="foo" value="bar"/>
>            </map:transform>
>            <map:serialize/>
>         </map:match>
>      <map:pipeline>
>   </map:pipelines>
> Even passing parameters to the transformer could be achieved easily by
> adding them to the stack of sitemap variables.
> There is one problem though: dependencies among such declarations
> would make eager initilization difficult. Lazy initialization would
> produce errors only run-time so a mixture needs to be applied.

and to add IMHO it doesn't really help in
- general sitemap readability
- separating the logic bits from the pipeline-config bits
...but I might be the only one seeing this last emerging 
advantage in this discussion?

I think flow proves (in an elegant way) that this separation is 
achievable, so I really would like to see that approach infect 
what we already have.

> 	Chris.

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message