cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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:
>>    
>>

<snip/>

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

<snip/>

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

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

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message