cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] reconsidering pipeline semantics
Date Wed, 03 Jul 2002 09:14:53 GMT
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.

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.

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

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

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

For example, what is the difference between

 <generate .../>
 <transform type="pipeline" src="/blah"/>
 <serialize .../>

and 

 <generate .../>
 <call pipeline="blah"/>
 <serialize .../>

???

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.

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

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message