cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Fri, 22 Nov 2002 18:36:49 GMT
Sylvain Wallez wrote:
> The discussions around Stefano's "Cocoon blocks version 1.1" showed the 
> need for pipelines to provide not only resources, but also services, 
> identified by their URI.
> This document defines this concept of "pipeline service", which, as we 
> will see, consists in using pipelines as sitemap components (generator, 
> transformer and serializer). It is separated from the blocks design 
> document since pipeline services can be used without blocks, even if 
> they will be mostly useful in that context.

Thanks for writing this Sylvain, it's very helpful.


In short, what you are describing is a model for pipeline extension: one 
pipeline 'extends' another pipeline by calling it and cocoon 
transparently adapts it by removing the parts which aren't useful.

I do see the problem of cocoon transparently removing pipeline 
components, but it feels more like OOP inheritance where the system 
transparently ignores the overloaded method.

Yes, the parallell is a little streched, but I think that the fact that 
nobody ever complained about the fact that serializers are ignored on 
cocoon: subpipeline calls makes me think that the concept is not so 

Moreover, the fact of allowing *complete* pipelines is also tremendously 
helpful for debugging purposes and for block-reuse: instead of having 
passive pipeline fragments, we'll have the ability to write a pipeline, 
test it and then extend it with another.

Note that a pipeline might still be required to be called directly.

For example:

  <match pattern="*.xml">
   <generate type="file" src="{1}.xml"/>
   <serialize type="xml"/>

  <match pattern="*.html">
   <generate type="pipeline" src="{1}.xml"/>
   <transform src="xml2html.xslt"/>
   <serialize type="html"/>

  <match pattern="*.pdf">
   <generate type="pipeline" src="{1}.xml"/>
   <transform src="xml2fo.xslt"/>
   <serialize type="fo2pdf"/>

The nice thing would the above is that if the generation of the *.xml 
resource is changed, this is automatically inherited by all the 
pipelines that build on it.

Note that one might also want to connect to "views" of those pipeline... 
so for example why don't we add the ability to specify which "view" of 
the pipeline we should start from?

  <map:generate type="pipeline" src="/whatever/resource" view="content"/>

What do you think think?

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message