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: http://wiki.cocoondev.org/Wiki.jsp?page=ResourceNaming
(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 confusion?
(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= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
