On Tuesday, July 2, 2002, at 01:54 PM, Stefano Mazzocchi wrote:
> In light of the discussion on blocks, Sylvain pointed out that cocoon
> services should be mapped to pipelines and not to resources directly.
>
I totally agree with that suggestion.
<snip/>
>
> We call 'Cocoon pipeline' the collection of all filters (transformers)
> and adapters (generator and serializer) because there cannot be a
> pipeline without adapters.
>
> I think it's time to challenge this concept.
>
Great!
> - o -
>
> What are sitemap resources?
> ---------------------------
>
> Let me tell you: they are a mistake, a mistake I did trying to reduce
> the sitemap verbosity and fixing a problem that didn't yet emerged at
> that time. Early optimization is the root of all evil and I see that
> now: resources overlap with pipelines.
>
+ 1x10^6
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
>
<snip/>
> Composing pipelines
> -------------------
>
> Let me assume the above syntax gets introduced. At this point, we have
> four different ways to call a pipeline:
>
> - as a pipeline
> - as a generator
> - as a transformer
> - as a serializer
>
> let me write the code so you understand what I mean:
>
> [using a pipeline as a pipeline] (as today)
>
> <pipeline>
> <match pattern="*">
> <call pipeline="blah"/>
> </match>
> </pipeline>
>
> nothing fancy here. Used mainly for verbosity reduction when the same
> pipeline is used in different places.
>
> [using a pipeline as a generator]
>
> <pipeline>
> <match pattern="*">
> <call pipeline="blah"/>
> <transform .../>
> <serialize ../>
> </match>
> </pipeline>
>
these are both the same as:
<pipeline>
<match pattern="*">
<generate src="cocoon:/blah"/>
</match>
</pipeline>
> in this case, the 'serializer' of the called pipeline is not used and
> the output of the last tranformer of the named pipeline is connected
> with the input of the transformer right after the call.
>
> This is equivalent of *overloading* the serializer of the called
> pipeline with the rest of the pipeline in place.
>
> [using a pipeline as a transformer]
>
> <pipeline>
> <match pattern="*">
> <generate ../>
> <call pipeline="blah"/>
> <serialize ../>
> </match>
> </pipeline>
>
This we cannot currently do, and it would be an excellent addition!
We have two different transformation types here (as others have
pointed out)
1. a sub-pipeline that generates an XSLT Stylesheet
2. a sub-pipeline that does some transformations for you
Case 1 you do like this:
<map:transform src="cocoon:/make-xslt"/>
Case 2 we cannot do right now and would be a great addition!
> where both the generator and the serializer of the named pipeline are
> not used.
>
so why have them in there?
> This is equivalent of *overloading* both the generator and the
> serializer of the called pipeline with the rest of the pipeline in
> place.
>
> [using a pipeline as a serializer]
>
> <pipeline>
> <match pattern="*">
> <generate ../>
> <tranform ../>
> <call pipeline="blah"/>
> </match>
> </pipeline>
>
> where the generator of the named pipeline is not used.
>
> This is equivalent of *overloading* the generator of the called
> pipeline
> with the rest of the pipeline in place.
>
> - o -
>
> So, here is what I propose:
>
> - add the 'pipeline' attribute to 'map:call'
> - add the 'name' attribute to 'map:pipeline'
I think it is interesting that you want to do this to the
pipeline rather than individual matchers.
Hmm.
Considering you can do this in XSLT:
<xsl:template match="blah/*" name="call-blah"/>
to make a template that can be 'called' in two different ways ....
Would it make more sense to do this instead?:
<map:match pattern="blah/*" name="call-blah"/>
> - deprecate the 'map:resources' element
you can replicate this with map:redirect-to (internal redirect?)
> - deprecate 'internal-only' attribute of 'map:pipeline'
> [because named pipelines become implicitly internal-only]
See above ....
> - allow 'map:call' to be executed in any place, performing the
> pipeline
> overloading behavior I explained above.
>
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 ;)
I think 'underloading' ;) would make it easier to read the sitemap.
ie. I call an internal pipeline, if that pipeline serialises, I do not.
So following on from that (maybe this is where it breaks down),
if you call an internal pipeline which generates, it's output
replaces yours (!).
> What do you think?
>
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!
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
