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:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
