Hi Guys,
FYI, I have submitted a patch (Bugzilla [Bug 11386]) which completes
auto caching-point
(Bugzilla [Bug 11131] should also probably be applied along side this
patch..because it fixes a general bug in the pipeline imlementations)
So in SUMMARY (as dicussed/agreed in earlier threads)
this patch implements auto caching-point as follows
------------
For pipelines that implement caching-point:
if the ProcessingNode is of type
SimpleParentProcessingNode and the generator is already set
and Node has one or more children, then return true;
this is a caching-point
or
if the ProcessingNode is of type
PipelineEventComponentProcessingNode
and has one or more views set, then return true; this is a
caching-point
This "auto" behavior can be switched On/Off vi sitemap.xmap configuration
of the caching-point pipeline
<autoCachingPoint>On</autoCachingPoint>
------------
The manual(ie pipeline-hint="caching-point") behavior is
meant to be always supported by caching-point pipelines.
(but its not yet fully implemented)
In the next week(s) I will try to to complete the "pipeline-hint"
manual caching as decribed in this thread.
Regards,
Michael Melhem
On Fri, Jul 26, 2002 at 12:40:34PM +0200, Michael Melhem wrote:
> On Fri, Jul 26, 2002 at 11:28:11AM +0200, Sylvain Wallez wrote:
> > 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.
>
> Ok good, PipelineComponentProcessingNode it is then!
> >
> > <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.
>
> Yep sure.
>
> >
> > 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).
>
> I cant argue with that.
>
> >
> > 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.
>
> I agree, we dont want each pipeline implementing its own parsing, its the job of
> the treeprosessor to interpret the sitemap. The pipeline implementation simply acts
>on
> the information it receives.
>
> >
> > This requires a change in the Pipeline interface, since we must add this
> > Parameters object to each component addition method.
>
> The Add and Set Methods on the Pipeline interface already take a
> "Parameters" object. So that should make that easy!
>
> >
> > Thoughts ?
>
> Carsten is still on holiday, but it would be interesting to get his
> input on this.
>
> I have a patch almost ready which will include the new
> PipelineComponentProcessingNode (with the cocoon views stuff).
> >From there it shouldnt be too difficult to extended it to implement
> this PROSPOSAL.
>
> Regards,
> Michael Melhem
>
> >
> > Sylvain
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies Apache Cocoon
> > http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
