cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Overloaded pipeline elements (Was Re: [RT] FOM)
Date Wed, 28 May 2003 06:38:32 GMT

Miles Elam wrote:
> Stefano Mazzocchi wrote:
>> on 5/27/03 4:19 PM Sylvain Wallez wrote:
>>> How is this different from a resource? Resources also allow to define 
>>> overloaded generators and transformers. So do we really need a new 
>>> concept ?
> ...
>> Resources were supposed to be reusable pipelines, but *complete* ones!
>> Later, they were implemented to be usable as pipeline fragments but,
>> IMO, they impose some readability problems in the sitemap. The above
>> aims to correct that.
>> In fact, if the above is introduced, I would deprecate the use of
>> resources that do not have a complete pipeline.
> What is the purpose of resources if this new syntax goes into effect 
> (which I like by the way)?  What can a resource do that an overloaded 
> pipeline element cannot?

I think as Stefano said (slightly rephrased): it would deprecate 
the use of resources that are only fragments of pipelines.

Also looking at:
(implicitely stressing the readability issus in the sitemap here)

the 4th thingy to think about in this context is indeed complete 
pipelines, in fact the question pops up if we wouldn't want to 
have overloaded complete pipelines as well?

I really like the concept of pipelines being reuseable things one 
can 'call', meaning with a given set of named arguments.  (This 
is also how the use of sendPageAndWait() inside Flow kind of puts 
the role of these pipelines... big difference however in 
how/where the passed Map is interpreted)

 From that 'calling' perspective: Declaring the pipelines inside 
the matchers as we do nowadays is a bit like inlining / copying 
your private methods in Java-code...

In the case of the sitemap this 'inlining' kind of leads to 
cluttering both processing(ie decision making in matchers, 
selectors, actions...) and configuration(really defining the data 
production pipe)
[In my experience: A cluttering that is kind of confusing to a 
lot of first time users]

Mmm, one step further might thus be splitting this up in the 
sitemap just like the use of flowscript is splitting it up?
Then the use of macthers, selectors, actions is banned to some 
<map:process> element from where the defined pipelines are called?

(only remains the issue of different return-Map handling)
(oops, and the one of backwards compatibility of course)

> Also, would this add to the learning curve?  The docs would need to reflect
>  overloaded generator contains exactly one generator and one or more 
> transformers
>  overloaded tranformers contain two or more transformers
>  overloaded serializers contain one or more transformers and exactly one 
> serializer

yep, and code should verify and generate meaningful 
warnings/errors IMHO

> Once people grasp the concept of a pipeline and understand it 
> completely, this will be a no-brainer.  But I expect there will be a 

and vice versa: this could help them grasp the concept :-)

> large number of people who will come to the list asking about why their 
> overloaded generator doesn't work because they added a serializer to the 
> definition as in:
>  <map:generators>
>    <map:generator name="html" src="tidy stuff"/>
>    <map:generator name="html">
>      <map:generator type="html"/>
>      <map:transformer type="linkrewriter"/>
>      <map:serializer type="html"/>
>    </map:generator>
>  </map:generators>
> and then
>  <map:pipeline>
>    <map:match pattern="foo">
>      <map:generate type="html" src="foo.html"/>
>    </map:match>
>  </map:pipeline>
> I think the expectation that a "super()" method would be called by 
> overloading the pipeline element is asking for trouble with regard to 
> user confusion.

Is this more then an issue of naming this concept? I we call this 
'assembled' or 'composed' pipeline elements we can maybe prevent 
(this thread's subject will need to be erased from history 
however ;-))

> Personally I would be happy to see the new syntax (pipeline component 
> groups), but is all of the baggage accounted for?  Or would clear error 
> messages be sufficient to mitigate major problems?

that and backwards compatibility of the deprecated resources for 
some time maybe?

> - Miles Elam

more ideas?
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message