Unico Hommes wrote:
Unico Hommes wrote:
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
<snip/>
Oh but I think I see now. The cache-key and cache-validity objects
are associated with the compiled template object using template
properties. The compiled template in turn is cached directly by the
generator using the validity of the src of the generator. That
should work.
So now how to use this feature. If I read this correctly cache-key
and cache-validity attributes can be specified on an element
anywhere in the xml:
<element jx:cache-key="${cacheKeyExpression}"
jx:cache-validity="${cacheValidityExpression}" />
Yes it is. I am thinking about a slight change. Right now every xml
node is parsed for jx:* attributes. What I would like to do is to
introduce
<jx:processing instruction name="cache-key" value="${expr}"/>
wdyt?
Yes, I agree it would be better not to check each element for these
attributes. <jx:processing-instruction/> sounds like a good option to me.
There is one other thing. The cache key that is returned by
JXTemplateGenerator should be the src + jx:cache-key attribute value.
Since the jx:cache-key is only a hash of the objects that are used in
the template. These could, in theory, be the same as those objects used
by another template. Therefore it is neccessary to also qualify the
cache key with location of the template.
Shouldn't it be done automatically by cocoon? So the cocoon is always composed
of view id and cache key? Why would user need to share cache-keys between views?
--
Leszek Gawron [EMAIL PROTECTED]
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65