cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] reconsidering pipeline semantics
Date Wed, 03 Jul 2002 20:51:00 GMT
Jeremy Quinn wrote:


> I never liked map:resource, always having to be at the end, makes them 
> far less useful for pipeline reuse!
> It's like going to a plumber's merchant to buy some joints and they 
> say 'yes we have elbows and tee joints, but they are all pre-assembled 
> into special shapes, you cannot buy them individually'. :P 

What if resources didn't have to be terminated, thus being arbitrary 
pipeline snippets (teasing, see below) ?


> I think overloading is a grand idea in principal, though I fear it 
> will be confusing and difficult to understand in this context (unless 
> you are a Java architect ;) 

Same fear here, even if I'm a Java architect ;)


> I think the idea of having a pipeline snippet, that is able to be 
> 'called' from the middle of another pipeline is a great idea, it 
> allows much more effective componentisation and the ability to hide 
> complexity (in blocks or other pipelines/sitemaps).
> What I am not so happy about is being forced to put a component 
> (generator|serializer) into a pipeline, when it is obviously not going 
> to be used!
> IMHO calling a pipeline snippet (for whatever purpose) should be 
> equivalent to XIncluding that pipeline snippet into the calling 
> pipeline at Sitemap runtime.
> So:
>     <map:call pipeline="blah"/> includes pipeline components
> While:
>     <map:generate src="cocoon:/blah"/>,
>     <map:transform src="cocoon:/blah"/> and
>     <map:part src="cocoon:/blah"/> import pipeline output
> Anyway, I think this (general idea) will lead to great improvements!

Jeremy, this resonates with what I proposed at 
(see at the bottom, I forgot to snip...), and here are some additional 
inputs :

A resource is a sitemap snippet, which is used locally in the current 
sitemap, and is only visible from this sitemap. The treeprocessor 
currently "silently" extends the resource definition by allowing a 
resource to be unterminated (i.e. no serializer). This wasn't done on 
purpose (this is in fact a bug if resources must be terminated), but we 
can make it official.

Defined this way (a pipeline snippet, without mandatory serializer), a 
resource is equivalent (minus its additional parameters) to inlining its 
content at the location of the <map:call>.

Using pipelines to define other pipelines came from a different need, 
which is to identify cross-sitemap/block services. I don't like named 
pipelines, since the current scope of resource names is limited to the 
sitemap that defines them. Using names to identify cross-sitemap/block 
services will add a new contract when we already have one : the sitemap 
environment, and mainly its request URI, as used by the "cocoon:" protocol.

That's why I'm in favor of a more explicit semantic that both :
- differenciates internal snippets (a writing facility) and pipeline 
services (inter-sitemap/block contracts),
- clearly states what should be used in pipeline services, and not rely 
on implicit overloading.


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

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

View raw message