cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: Overloaded pipeline elements (Was Re: [RT] FOM)
Date Wed, 28 May 2003 11:07:38 GMT
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
> Christian Haul wrote:

> >  <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>

> >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?

Don't get it. If only generate, transform, and serialize is allowed,
then these fragments may be used to factor out common parts -- simple
parts to be precise. Hiding complexity away has proven successful in
programming. But that requires IMHO to allow some logic e.g. matchers
and selectors as well.

Another approach would be to assemble the pipeline fragments through
flow but that seems to spoil SoC.

Could you elaborate a little more how you envision this separation,
perhaps with a little example?

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Mime
View raw message