You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Melhem <mi...@fztig938.bank.dresdner.net> on 2002/07/25 18:31:15 UTC
Auto/Manual_Cachingpoints pipelines & Cocoon-Views
Dear Cocoon Gods,
(Flattery will get you everywhere!)
In Particular:
Attn: Sylvain Wallez
Attn: Carsten Ziegeler
FYI, I have been working to complete "cachingpoint" (CP) pipelines so
that auto CP (ACP) is fully functional (and capable of supporting
manual cachingpoint).
Changes include:
1. Cachingpoint pipeplines implement configurable. So
its now possible to switch between cachingpoint policies easly.
<map:pipeline name="cachingpoint" src="...impl.CachingPointProcessingPipeline">
<cachingpoint-policy>...AutoCachingPointStrategy</cachingpoint-policy>
<!-- cachingpoint-policy>...ManualCachingPointStrategy</cachingpoint-policy -->
</map:pipeline>
2. Introduced a new TreeProcessor Node called
SimpleLeafProcessingNode.java (as opposed to SimpleParentProcessingNode).
SimpleLeafProcessingNode groups the common cocoon-views behavior at higher
level and makes it easier support manaul cachepoints etc.
Thoughts, comments ? :-P
THOUGHTS ON MANUAL CACHINGPOINTs (MCPs).
Does it make sense to have a MCP on anything other than "Leaf" Nodes?
That is, Nodes which dont subclass SimpleParentProcessingNode?
As with cocoon-views, I would say the answer is *no*..
ParentProcessingNodes are not candidates for MCP's)
The current cachingpoint behavior flags a cachingpoint whenever a
"leaf" node is indicated to have one or more "views". So in effect,
we already have a mechansim for manual cachingpoint (well close,
you still need to have a view defined).
I was thinking that one possibility is to extend this "views" behavior
so you can have something like the following:
<map:transform src="../simple-samples2html.xsl" label="cachingpoint"/>
Where in effect, you manually label a pipeline component as being a
cachingpoint. In this case, "cachingpoint" is not a view but a
"resevered" word to indicate that this component is a manual cachingpoint.
After this fashion, you can also label components as manual "cachingpoints"
within the <components> section of the sitemap.xmap (as with cocoon-views)
(alternatively you can seperate the concerns by having something like
<map:transform src="../simple-samples2html.xsl" cachingpoint="true"/>)
Any thoughts on this?
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views)
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
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:sylvain@apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views)
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
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:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints
pipelines & Cocoon-Views)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>
<snip/>
>>This requires a change in the Pipeline interface, since we must add this Parameters object to each component addition method.
>>
>>
>
>You want change interface to something like:
>
>public interface ProcessingPipeline {
> ...
> void setGenerator (String role, String source,
> Parameters param, Parameters hint);
> ...
>}
>
>
Exactly !
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
RE: [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
...
> 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.
You want change interface to something like:
public interface ProcessingPipeline {
...
void setGenerator (String role, String source,
Parameters param, Parameters hint);
...
}
?
Vadim
> 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
Re: [PROPOSAL] Pipeline hints
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
Hi,
Re: Bugzilla [Bug 12227]
FYI, this patch implements "pipeline-hints" as discussed on cocoon-dev
mailing-list.
Breifly, "pipeline-hints" is the ability to provide
"hints" to pipelines to indicate that certain behavior
is desired when adding a pipeline-component to the pipeline. This hint
takes the form of an extra "hintParam" Parameters Object in the "set" and
"add" methods of the ProcessingPipeline interface.
This patch provides a first stage implementation (and does yet fully
implement the planned syntax as Proposed by Sylvain Wallez below). But
can easily be extended to do so.
This patch also alters the caching-point pipeline implementation so that
it accepts caching-points "hints" to indicate manual caching points!
so that <map:transform src="../simple-samples2html.xsl" hint="caching-point"/>
will hint to the pipleline that this is a manual caching point.
Of course, pipeline implementations which do not support certain hints
silently ignore them.
What do you guys think?
Regards,
Michael Melhem
On Fri, 26 Jul 2002, Sylvain Wallez wrote:
> 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).
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines
& Cocoon-Views)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Thu, Jul 25, 2002 at 09:44:56PM +0200, Sylvain Wallez wrote:
> Michael Melhem wrote:
>
> >Dear Cocoon Gods,
> >(Flattery will get you everywhere!)
> >
>
> We're not god, but only grown-up contributors ;)
>
> >In Particular:
> >Attn: Sylvain Wallez
> >Attn: Carsten Ziegeler
> >
> >FYI, I have been working to complete "cachingpoint" (CP) pipelines so
> >that auto CP (ACP) is fully functional (and capable of supporting
> >manual cachingpoint).
> >
> >Changes include:
> >1. Cachingpoint pipeplines implement configurable. So
> >its now possible to switch between cachingpoint policies easly.
> >
> ><map:pipeline name="cachingpoint"
> >src="...impl.CachingPointProcessingPipeline">
> > <cachingpoint-policy>...AutoCachingPointStrategy</cachingpoint-policy>
> > <!--
> > cachingpoint-policy>...ManualCachingPointStrategy</cachingpoint-policy -->
> ></map:pipeline>
> >
> >2. Introduced a new TreeProcessor Node called
> >SimpleLeafProcessingNode.java (as opposed to SimpleParentProcessingNode).
> >
> >SimpleLeafProcessingNode groups the common cocoon-views behavior at higher
> >level and makes it easier support manaul cachepoints etc.
> >
> >Thoughts, comments ? :-P
> >
>
> 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?
>
> >THOUGHTS ON MANUAL CACHINGPOINTs (MCPs).
> >
> >Does it make sense to have a MCP on anything other than "Leaf" Nodes?
> >
>
> ...other than "pipeline statement" Nodes ? :)
>
> >That is, Nodes which dont subclass SimpleParentProcessingNode?
> >
>
> Be careful here : you're mixing implementation helper classes (that
> aren't related to the sitemap at all) with your specification of the the
> sitemap statements that can define a cache point. Let's not bias the
> spec by "implementation details", as Stefano likes to call them !
>
> >As with cocoon-views, I would say the answer is *no*..
> >ParentProcessingNodes are not candidates for MCP's)
> >
> >The current cachingpoint behavior flags a cachingpoint whenever a
> >"leaf" node is indicated to have one or more "views". So in effect,
> >we already have a mechansim for manual cachingpoint (well close,
> >you still need to have a view defined).
> >
> >I was thinking that one possibility is to extend this "views" behavior
> >so you can have something like the following:
> >
> > <map:transform src="../simple-samples2html.xsl" label="cachingpoint"/>
> >
> >Where in effect, you manually label a pipeline component as being a
> >cachingpoint. In this case, "cachingpoint" is not a view but a
> >"resevered" word to indicate that this component is a manual cachingpoint.
> >
> >After this fashion, you can also label components as manual "cachingpoints"
> >within the <components> section of the sitemap.xmap (as with cocoon-views)
> >
> >
>
> Although this reserved view name seems elegant at first, it finally
> seems to me like a hack, as we use a totally different concept (the
> views) to configure the pipeline caching behaviour.
>
> >(alternatively you can seperate the concerns by having something like
> > <map:transform src="../simple-samples2html.xsl" cachingpoint="true"/>)
> >
> >
>
> This seems more clear, but introduces attributes on sitemap components
> related to a particular implementation of the pipeline, so I don't like
> it so much either : what if several pipeline implementations require
> some special attributes ?
>
> >Any thoughts on this?
> >
> >
>
> 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"/>
Best Regards,
Michael Melhem
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>Dear Cocoon Gods,
>(Flattery will get you everywhere!)
>
We're not god, but only grown-up contributors ;)
>In Particular:
>Attn: Sylvain Wallez
>Attn: Carsten Ziegeler
>
>FYI, I have been working to complete "cachingpoint" (CP) pipelines so
>that auto CP (ACP) is fully functional (and capable of supporting
>manual cachingpoint).
>
>Changes include:
>1. Cachingpoint pipeplines implement configurable. So
>its now possible to switch between cachingpoint policies easly.
>
><map:pipeline name="cachingpoint" src="...impl.CachingPointProcessingPipeline">
> <cachingpoint-policy>...AutoCachingPointStrategy</cachingpoint-policy>
> <!-- cachingpoint-policy>...ManualCachingPointStrategy</cachingpoint-policy -->
></map:pipeline>
>
>2. Introduced a new TreeProcessor Node called
>SimpleLeafProcessingNode.java (as opposed to SimpleParentProcessingNode).
>
>SimpleLeafProcessingNode groups the common cocoon-views behavior at higher
>level and makes it easier support manaul cachepoints etc.
>
>Thoughts, comments ? :-P
>
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).
>THOUGHTS ON MANUAL CACHINGPOINTs (MCPs).
>
>Does it make sense to have a MCP on anything other than "Leaf" Nodes?
>
...other than "pipeline statement" Nodes ? :)
>That is, Nodes which dont subclass SimpleParentProcessingNode?
>
Be careful here : you're mixing implementation helper classes (that
aren't related to the sitemap at all) with your specification of the the
sitemap statements that can define a cache point. Let's not bias the
spec by "implementation details", as Stefano likes to call them !
>As with cocoon-views, I would say the answer is *no*..
>ParentProcessingNodes are not candidates for MCP's)
>
>The current cachingpoint behavior flags a cachingpoint whenever a
>"leaf" node is indicated to have one or more "views". So in effect,
>we already have a mechansim for manual cachingpoint (well close,
>you still need to have a view defined).
>
>I was thinking that one possibility is to extend this "views" behavior
>so you can have something like the following:
>
> <map:transform src="../simple-samples2html.xsl" label="cachingpoint"/>
>
>Where in effect, you manually label a pipeline component as being a
>cachingpoint. In this case, "cachingpoint" is not a view but a
>"resevered" word to indicate that this component is a manual cachingpoint.
>
>After this fashion, you can also label components as manual "cachingpoints"
>within the <components> section of the sitemap.xmap (as with cocoon-views)
>
>
Although this reserved view name seems elegant at first, it finally
seems to me like a hack, as we use a totally different concept (the
views) to configure the pipeline caching behaviour.
>(alternatively you can seperate the concerns by having something like
> <map:transform src="../simple-samples2html.xsl" cachingpoint="true"/>)
>
>
This seems more clear, but introduces attributes on sitemap components
related to a particular implementation of the pipeline, so I don't like
it so much either : what if several pipeline implementations require
some special attributes ?
>Any thoughts on this?
>
>
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 ?
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