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 Thu, 04 Jul 2002 21:21:09 GMT
Sorry Stefano, I missed your mail in the flood yesterday.

Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>>Although it is ok to call named pipelines _inside_ a sitemap (that's
>>just a name change for resources), I don't like it for _inter sitemap_
>>calls, like can or will be the case for subsitemaps and blocks : up to
>>now, the input contract of the sitemap is the environment, and pipeline
>>choice is most often directed by the request URI. Does calling named
>>pipelines mean you want to add a new property to the environment, just
>>as the view and action we have today ?
>The design should not be constrained by implementation details, Sylvain.
>Try not to think about how to make it work for now.

Is the environment an implementation detail ? Maybe...

>I've showed how I perceived named pipelines not as 'functions' to call,
>but as 'small internal URI spaces' (sort of small internal virtual
>hosts), I think this concept is *much* more powerful than the
>'resources' we have now and it's much more block-friendly.

If they are "small internal URI spaces", is it necessary to name them ? 
Isn't the regular URI-matching enough that you need an additional naming 
scheme ?

>>IMO, the called pipeline should be defined by an URI, just as what we
>>already use for the "cocoon:" pseudo-protocol. This wouldn't introduce
>>yet-another naming scheme and would keep the existing sitemap contract.
>Yes, I do see the danger of adding another protocol for something that
>is equivalent in functionality, but I have the feeling that 'pipeline:'
>could slowly deprecate 'cocoon:' which IMO, would be a good thing in the
>longer term.
>[of course, I *DO*NOT* want to deprecated cocoon: , just to show
>different and more rational ways of doing things]
>The Cocoon: protocol is not block-friendly and we can't make it so
>without breaking back compatibility. Also, the name is too cocoon

You're right : its difficult to be more cocoon-specific than "cocoon" ;-)

>>Of course, we must keep today's resources as "named pipeline snippets"
>>inside a single sitemap. To answer Peter's request, we can allow a
>>resource to be not terminated (i.e. not contain a serializer). I even
>>think the treeprocessor already handles this (needs to be verified, though).
>>                              --o0o--
>>The second point I'm not comfortable with is implicit overloading. I
>>have the feeling the associated behaviour will be difficult to predict
>>and will make the sitemap hard to read by requiring lots of "look-ahead".
>Again, it's the implementation bias that leads your design judgement.

This feeling came from a sitemap reader/writer point of view. Consider 
the following :

<map:pipeline name="blah">
  <map:generate src="dummy.xml"/>
  <map:transform src="style.xsl"/>

  <map:match pattern="explicit.html">
    <map:generate src="explicit.xml"/>
    <map:call pipeline="blah"/>

  <map:match pattern="*.html">
    <map:generate src="data/{1}.xml"/>
    <map:transform src="xml2htm.xsl"/>


What will happen when "explicit.html" is requested ? Please consider it 
as the user wanting to understand what happens to its data :
- match "explicit.html" : matches, so we go in
- generate "explicit.xml" : added to the pipeline.
- "blah" pipeline is called
- generate in "blah" : won't be used as the caller already defined one.
- transform in "blah" : added to the pipeline.
- serialize in "blah" : added, but can potentially be overloaded by what 
will happen later in the caller.
- return to the caller
- match "*.html" : also matches, so we go in also !!
- generate "data/explicit.xml"...
==> What happens here ? <==

Does this implicitely mean the "explicit.html" pipeline is finished and 
can be processed ? Or does this mean the sitemap is erroneous because we 
want to add a generator when there's already one ?

This also means that we can't reliably define what will happen when we 
close the <map:match> for "explicit.html", since this depends on what is 
written after.

That's why I'm not comfortable with implicit overloading (even less 
after writing this example) and would prefer a more explicit writing _in 
the caller_ of what we want to use from the called pipeline.

>>Consider serializer overloading. The current sitemap definition says
>>that a pipeline is terminated when a <map:serialize> or <map:read> is
>>encountered. With the implicit overloading semantic, this rule is no
>>longer valid as the calling pipeline _may_ or _may not_ define another
>>serializer. And as any <map:serialize> that's present _below_ the
>><map:call> can theoretically terminate the pipeline, this means that
>>knowning if the called pipeline serializer is overloaded requires
>>traversal of the entire remaining part of the sitemap, even if all
>>remaining serializers are enclosed in <map:match> that will never match.
>Hmmm, wait, I don't get it. From an implementation point of view, I
>don't see how having explicit or implicit overloading makes any
>For example, what is the difference between
> <generate .../>
> <transform type="pipeline" src="/blah"/>
> <serialize .../>
> <generate .../>
> <call pipeline="blah"/>
> <serialize .../>

Does my detailed example above show more differences ?

>The pipelines are exactly the same (they could have tons of matchers and
>selectors and so on) and the resulting behavior is *exactly* the same.
>There are only two differences:
> - your example places a sitemap behavior inside a sitemap component.
>This appears to me an evident example of the use of the
>overcomponentization anti-pattern.

Why is it overcompentization ? There are no new component contracts 
defined here, but just the implementation of existing contracts. The 
"pipeline" transformer is just a composite one since it uses 
transformers defined by the pipeline.

> - you can't reuse the 'blah' pipeline in another location. So it is
>possible that you call a pipeline fragment which is wrongly terminated.
>With implicit overloading, the pipeline is always correctly terminated.

Why can't it be reused ? A pipeline always starts with a generator and 
ends with a serializer (not considering readers here).

What the "pipeline" transformer does is build a pipeline, which must 
follow the same rules as any pipeline, and use only its transformers 
(generator and serializer are ignored). Similarly, the "pipeline" 
generator will build the pipeline and use its generator and 
transformers. And so on for the serializer.


A lot, you've read them ;)


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

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

View raw message