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:15:54 GMT
Vadim Gritsenko wrote:

> 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.
>> 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.
> I see two issues to be resolved before Sylvain's proposal can be 
> implemented.
> First one is naming issue. It's very confusing (to me, and I bet to 
> users too) when ProcessingPipeline object built by sitemap engine 
> after sitemap execution is referenced in the sitemap simply as 
> "pipeline" - it can be very easiliy mistaken for map:pipeline section 
> (the whole different beast). Thus, I suggest we use "cocoon" type 
> instead of "pipeline" type. The reason is: because this name is more 
> similar to "cocoon" protocol which does very similar thing: it lets 
> you access ProcessingPipeline object, augment it, and use it.

Yep. I now use "cocoon" as you suggested in an earlier post.

> Second issue is that clear understanding of how this new components 
> relate to existing sitemap constructs such as views and resources. Its 
> mainly documentation issue I think. On the surface, "pipeline as 
> serializer" can be mistaken with a view, and "pipeline as transformer" 
> is somewhat similar to broken resources implementation in 2.1.

Resources are internal only to a sitemap, so this proposal doesn't 
affect the way they're handled. BTW what's broken about resources in 2.1 ?

As for views, we already have defined how view relate to the "cocoon:" 
protocol. So I would use the same behaviour, which uses the well-known 
"cocoon-view" request parameter.


> Can we do not use "pipeline" word for these components? That's the 
> major concern I have.

As I said previously, I now use the "cocoon" word, which is best suited, 
as you suggested.


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

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

View raw message