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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
