cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <sharkb...@mac.com>
Subject Re: [RT] reconsidering pipeline semantics
Date Wed, 03 Jul 2002 10:59:21 GMT

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message