cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Sat, 23 Nov 2002 22:06:36 GMT
Stefano Mazzocchi wrote:

> 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.
> [snip]
> 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 unfriendly.

I'm not sure we can say that a pipeline "extends" another one, as this 
happens at a particular part of the calling pipeline, and we could even 
have a pipeline composed of several other pipelines. This is more 
related to defining a function, but even then the parallel is stretched.

This should be more considered as defining composite sitemap components 
: for example, the "cocoon" (better name than "pipeline") generator is 
composed of a generator and a set of transformers.

> 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>
>  <match pattern="*.html">
>   <generate type="pipeline" src="{1}.xml"/>
>   <transform src="xml2html.xslt"/>
>   <serialize type="html"/>
>  </match>
>  <match pattern="*.pdf">
>   <generate type="pipeline" src="{1}.xml"/>
>   <transform src="xml2fo.xslt"/>
>   <serialize type="fo2pdf"/>
>  </match>
> 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.

Good example : this shows that a pipeline can be used, depending on the 
context, either as a complete pipeline, or as a service (a generator in 
the above sample).

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

Thinking twice is certainly better than once ;-)

We can already can choose the view for a "cocoon:" resource by means of 
the standard "cocoon-view" parameter. So I would avoid adding a new 
attribute and simply write

<map:generate type="cocoon" src="/whatever/resource?cocoon-view=content"/>


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

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

View raw message