Leszek Gawron wrote:
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:8888/blocks/cocoon-template-sample/view/caching3
The template header is:
<page xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
jx:cache-key="${cocoon.request.parameters.toString()}"
jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}">
you probably may do the same with
jx:cache-key="${cocoon.parameters.toString()}" which will automatically
build up cache-key out of all cocoon parameters passed to the template.
Haven't tested it though. This means you probably don't even need any
additional code to achieve your goals.
I see what you mean, and I agree that it would allow us to do what we
are doing now with our custom code.
BTW, we use Cocoon 2.1.8, not the trunk.
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache key.
Anyway this looks like FS from the start:
What do you mean by FS? False Security?
- if template makes use of all cocoon parameters they should be a part
of the cache key,
- if not - you shouldn't pass them instead of excluding.
Please comment.
These two statements are true, and exactly satisfy our requirements. You
may have other requirements, though.
What matters to me is this: in our projects we mainly use JXTG and XSLT,
and (as far as I can see from a user perspective) with our solution the
formation of the cache key is consistent between the two (cocoon
parameters == cache key). This is a big plus in the fragmented world of
Cocoon technologies.
Bottom line: we prefer different solutions and are both happy with them.
Good thing we live in a free world ;-)
Regards,
Niels