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 08:03:13 GMT

Nicola Ken Barozzi wrote:
> Marc Portier wrote, On 28/05/2003 8.38:
>> Miles Elam wrote:
> ...
>>> 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.
> Then we are basically killing resources, as complete pipelines can 
> already be used instead of resources.

wow, this statement really got me thinking like I missed 
something completely (could very well still be the case)

sudden insight (uh, heavily helped by colleagues) makes me think 
you refer to the use of the generate/@src="cocoon://..." 
pseudo-protocol and thus refer to (possible internal-only) 
pipelines to be matched by the sitemap

hmmm, the difference would be in the mechanism to pass named 
arguments to the pipe: as a map (the current resource way) or as 
detectable positions in a URI?

unclear to me what is the best though, and how/if we could/should 
then also make the interface to using these newly proposed 
overloaded pipeline elements the same (ie URI based rather then 
Map transfer based)

any arguments either way out there?

> ...
>> Is this more then an issue of naming this concept? 
> I mean, if we make use of resources as callable full or partial sitemap
> snippets, what would we loose that we instead get from using this new 
> concept?

we already have what you mention, the question is what could we 
win with this new idea:

+ increased and inherit readibility of the sitemap (ie. better 
then complying to the tips in the wiki-doco)

+ possibility to stronger typecheck (ie generate errors or 
warnings) the defined resources (pipeline elements) as being of 
the fragment-type (G,T or S) they are intended to be

and refering to my sudden idea of having a separate 'process' 
describing section:
+ clearer distinction (although not enforced cause of backwards 
compat I guess) between decision logic and config logic inside 
the sitemap
+ more logic stepup / positioning / transition to flow ?

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

View raw message