cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message