cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views)
Date Fri, 26 Jul 2002 09:28:11 GMT
Michael Melhem wrote:

>On Thu, Jul 25, 2002 at 09:44:56PM +0200, Sylvain Wallez wrote:
>>Michael Melhem wrote:


>>Shouldn't it be better "PipelineStatementProcessingNode" ? The concerned 
>>nodes are those that add a component to the pipeline, and not all leaf 
>>nodes (map:redirect and map:call are leafs).
>Thats right, I didnt like the name "Leaf" for the reasons you mentioned
>above, but couldnt think of a better name at the time....hmmm
>PipelineStatementProcessingNode I like, but what do you of
>PipelineComponentProcessingNode? Wouldnt that be more accurate?

Yes, it looks better.


>>What we want here is in fact to be able to give the pipeline (whatever 
>>its implementation) a hint on how it should handle a particular pipeline 
>>element. So we can simply allow a hint attribute to be specified on 
>>pipeline statements :
>> <map:transform src="foo.xsl" pipeline-hint="cachepoint"/>
>>This allows any pipeline implementation do define it's own hints (e.g. 
>>profiling or logging a particular pipeline component).
>>What do people think ?
>So you mean having the PipelineStatementProcesingNode 
>(or PipelineComponentProcessingNode) make available a pipeline-hint 
>to the implementing pipeline.
>I See...this sounds more generic, because the attribute is 
>not specific to one particular pipeline implementation. I like it.
>I imagine one could also set multiple pipeline-hints: 
>  <map:transform src="foo.xsl" pipeline-hint="cachepoint,profilepoint"/>

Exactly !

Note that this attribute can also be placed on component declarations. 
But because several pipelines implementations can be used in a single 
sitemap, an implementation should silently ignore hints it doesn't 

Proposed syntax for pipeline hints :
// A hints attribute has one or more comma separated hints
hints-attr :: hint [ ',' hint ]*
// A hint is a name and an optional value
// If there is no value, it is considered as a boolean "true"
hint :: litteral [ '=' litteral ]
litteral :: <a character string where ',' and '=' must be escaped with '\'>

This allows the following :
pipeline-hint="caching-point, connector=profiling"

Note also that sitemap variable expansion applies as usual :
pipeline-hint="caching-point={want-cache}" where "want-cache" is a 
sitemap variable (either a Boolean or a true/false string).

Talking about implementation now, what about translating this hint 
attribute to a Parameters object ? This would allow the parsing of hints 
to be centralized in both time and space :
- in time, because it would occur only once at sitemap load-time,
- in space, because it will be the responsibility of the sitemap engine, 
thus avoiding each pipeline implementation to code its own parsing.

This requires a change in the Pipeline interface, since we must add this 
Parameters object to each component addition method.

Thoughts ?


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message