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] reconsidering pipeline semantics
Date Wed, 03 Jul 2002 20:51:00 GMT
Jeremy Quinn wrote:

<snip/>

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

<snip/>

> 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 ;)

<snip/>

> 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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102564464204469&w=2 
(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

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message