cocoon-dev mailing list archives

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

> Vadim Gritsenko wrote:

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

Actually, it was vice versa: that's was the first post, second I wrote 
later to show how your proposal could be misinterpreted ;-)
And may be to help clear up some misunderstanding.

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

My only point here is that I feel lots of users will ask questions. Some 
kind of doco will be needed.

> BTW what's broken about resources in 2.1 ? 

AFAIR, as of now, they do not enforce completeness of the pipeline. 
Officially, resource *must* be the complete pipeline, from generator to 
serializer. In practice, in 2.1, you can call resource and complete it 
later with transformer or two and serializer. I think, this practice 
shall be terminated (== bug fixed) when we implement <transform 

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

I mean here, that also some doco explaining what's <serialize 
type="cocoon"> is and what's the difference with view (view is also 
kinda serialize ;) is required.

> <snip/>
>> 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. 

We are on the same page now. With terms and understanding. Which is a 
good thing.


> Sylvain

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

View raw message