>
> Hello
>
> AFAIK, Cocoon caching mechanism tries to cache a pipeline processing
> workflow "until it meets a non-cacheable element" (correct me if I'm
> mistaken :)).
>
> My question is rather simple, given the above hopefully correct
> assumption. If I have a pipeline with type="caching" that looks like :
Normal caching pipeline does not work like this:
A cocoon pipeline is only cached cached (apart from expiring cache which works
little differnt, and the CachingPointProcessingPipeline ), if EVERY single
thing in it can be cached. So, if you have a very long pipeline, with 100
transformers, all cached very well, except, for example, your last transformer
not (like a dynamic i18n transformer which is implemented in a noncaching
pipeline), then, your entire pipeline wont be cached! (cocoon tries to create
just 1 cachekey for 1 pipeline. It can not have 1 cachekey for the first parts
of the pipeline (unless you are planning to use CachingPointProcessingPipeline))
If you have one single part in the pipeline which is uncacheable, there is no
difference in performance wether you use caching or non-caching pipelines.
But, if the last part of your pipeline is uncacheable, but for example the xml
generator is, then you can use in the map:part a src="cocoon:/cacheable/foo/bar"
and make sure that the /cacheable/foo/bar pipeline is cached. This way, at
least the generation of you xml is cached. This is more or less comparable to
CachingPointProcessingPipeline I think....
>
> <map:match pattern="foo">
> <map:aggregate element="root">
> <!-- various map:part reading xml flat files on disk which are
> sometimes updated -->
> </map:aggregate>
> <map:transform src="{myinputmodule:someproperty}/foo.xslt"/>
> <map:serialize type="xml"/>
> </map:match>
>
> and given that the someproperty output value is dynamic, because based
> on dynamic request parameters the myinputmodule uses to alter that
> property :
This is certainly not a reason why it can not be cached (what about
request-parameters passed into an xsl. An xsl can still be perfectly cached!!)
>
> will Cocoon cache the first inputmodule return value, and use it until
> the cache has to be refreshed, or will it *instead* cache each and
> every inputmodule value returned ?
I dont really know what you mean, but it depends on your myinputmodule
implementation
>
> in other words, will I end up with one cached xslt transformation
> bound to the first inputmodule value ever returned, or with multiple
> cached transformations, because Cocoon is "smart enough" to understand
> the transformer part uses a dynamic source, knowing that the {} might
> return different values ?
You just have to make sure, that depending on the request-param, your
myinputmodule returns a cached "someproperty" depending on the
request-parameter you want it to depend on. (like an xsl transformation, you
pass in map:paramters, where the cache then also depends on ( unless you
configure "use-request-parameters" to "true" for xsl transformations, then it
uses ALL request-parameters, which you should never do if you ask me))
Hope this clears things up.
Ard
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-------------------------------------------------------------
[EMAIL PROTECTED] / http://www.hippo.nl
--------------------------------------------------------------
>
> thanks
> laurent
>
>
> --
> <a href="http://in-pocket.blogspot.com";>http://in-pocket.blogspot.com
> - Mobile world, technology and more</a>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
