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 Fri, 05 Jul 2002 17:43:22 GMT
Sylvain Wallez wrote:

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

good point.

> Isn't the regular URI-matching enough that you need an additional naming
> scheme ?

No, probably not, but in that case, we need another pipeline state.

 - [no attribute] -> similar to java 'public'
 - internal-only="true" -> similar to java 'private'
 - ?? -> similar to java 'protected'

where the pipeline is accessible from the inside and from other blocks,
but not exposed to the public URI space.

Unfortunately, this requires a different attribute, something like

 <pipeline exposure="(public|internal|block)">

where exposure="public" is implicitly considered if the attribute is not
found and 'internal-only="true"' gets deprecated and falls back to
'exposure="internal"'.

NOTE: the attribute name 'exposure' is not mandated... it's just the
first that popped up on my mind.

> 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:serialize/>
> </map:pipeline>
> 
> <map:pipeline>
>   <map:match pattern="explicit.html">
>     <map:generate src="explicit.xml"/>
>     <map:call pipeline="blah"/>
>   </map:match>
> 
>   <map:match pattern="*.html">
>     <map:generate src="data/{1}.xml"/>
>     <map:transform src="xml2htm.xsl"/>
>     <map:serialize/>
>   </map:match>
> 
> </map:pipeline>
> 
> 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 ? <==

Gotcha! Your explaination of the concept shows that I was not able to
show you what I mean and I do see why now.

Let me try again (see below)

> 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
> >difference.
> >
> >For example, what is the difference between
> >
> > <generate .../>
> > <transform type="pipeline" src="/blah"/>
> > <serialize .../>
> >
> >and
> >
> > <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.

Yes, but you are moving a functional feature of the sitemap into a
component.

For example, we could have done:

 <map:generate type="aggregate">

instead of
 
 <map:aggregate ...>

but than we would have left the user the ability to 'remove'
functionality from the sitemap.

This is why I prefer to encode proper sitemap functionality in its
semantics, even if, implementation-wise, it would be equivalent to reuse
the existing component infrastructure.

Do you see my point?

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

Ok, there is a big impedence mismatch between your view of the concept
and mine and I think it's my fault.

My vision of pipeline overloading is triggered by the concept of
functional inheritance. Suppose you have a pipeline like this (named
"A")

 [A] gA -> t1A -> t2A -> sA

this is shipped and exposed by a major cocoon block. If this pipeline is
*exactly* the way I want it to be, I call it and that's it. But what if
I want to *extend* it? 

All right, you could copy it over to your own pipeline and continue, but
then you are forking. You are not using Pipeline A anymore, but your own
local copy, which, from now on, you'll have to maintain.

Following the OO patterns, I thought about using pipeline overloading to
perform pipeline inheritance. Admittedly, the use of the <map:call> tag
lead to misunderstanding, so I'll not use it here again.

Now, my own pipeline is something like this

 [B] gB -> t1B -> t2B -> sB

and I see these meaningful ways of extending the [A] pipeline with the
[B] pipeline:

 - 'gB' := 'gA -> t1A -> t2A'
 - 't1B' := 't1A -> t2A'
 - 't2B' := 't1A -> t2A'
 - 'sB' := 't1A - t2A -> sA'

In fact, you are not 'calling' a pipeline, but assembling an existing
pipeline differently, depending on the overloading information.

More explicitly:

[A] 
 <map:generate type="gA" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t2A" .../>
 <map:serialize type="sA" .../>

then the various possible pipelines become

[B]
 <map:import name="A"/>
 <map:transform type="t1B" .../>
 <map:transform type="t2B" .../>
 <map:serialize type="sB" .../>

which is equivalent to

 <map:generate type="gA" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t2A" .../>
 <map:transform type="t1B" .../>
 <map:transform type="t2B" .../>
 <map:serialize type="sB" .../>

or

[B]
 <map:generate type="gB" .../>
 <map:import name="A"/>
 <map:transform type="t2B" .../>
 <map:serialize type="sB" .../>

which is equivalent to

 <map:generate type="gB" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t2A" .../>
 <map:transform type="t2B" .../>
 <map:serialize type="sB" .../>

or

[B]
 <map:generate type="gB" .../>
 <map:transform type="t1B" .../>
 <map:import name="A"/>
 <map:serialize type="sB" .../>

which is equivalent to

 <map:generate type="gB" .../>
 <map:transform type="t1B" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t2A" .../>
 <map:serialize type="sB" .../>

or

[B]
 <map:generate type="gB" .../>
 <map:transform type="t1B" .../>
 <map:transform type="t2B" .../>
 <map:import name="A"/>

which is equivalent to

 <map:generate type="gB" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t1B" .../>
 <map:transform type="t1A" .../>
 <map:transform type="t2A" .../>
 <map:serialize type="sB" .../>

                                 - o -

While I admit the <call> semantic implied a jump and an execution of
another pipeline, here, we are simply specifying how a pipeline can make
use of another one in a more granular way.

NOTE: there is a functional overlap between

 <generate src="cocoon:/blah">

and 

 <import pipeline="/blah">

but I don't think this is harmful.

NOTE2: there is *NO* functional overlap between

 <tranform src="cocoon:/blah">

and

 <generate src="..."/>
 <import pipeline="blah"/>

since while in the first the src of the transformer is the output of the
'blah' pipeline, in the second it is *the* 'blah' pipeline (except the
generator which is overloaded) which gets appended to the pipeline.

                                 - o -

Admittedly, this very random thinking, but at least it will trigger
something in your synapses (hopefully :)

Ciao

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