Re: Caching JXTemplate
Unico Hommes wrote:
Leszek Gawron wrote:
Unico Hommes wrote:
...
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.
src/blocks/xsp/samples/java/cacheable.xsp:
/**
* Generate the unique key for the cache.
*
* This key must be unique inside the space of this XSP page, it
is used
* to find the page contents in the cache (if getValidity says
that the
* contents are still valid).
*
* This method will be invoked before the getValidity() method.
*
* @return The generated key or null if the component
* is currently not cacheable.
*/
public Serializable getKey()
{
// for our test, pages having the same value of "pageKey" will
share
// the same cache location
return "" + request.getParameter("pageKey");
}
That is why I thought the key is considered only in one page space.
Is this example broken ?
No.
Don't know, maybe XSP generator augments that key with the uri of the
XSP source before it returns it to the pipeline
ServerPagesGenerator [1], line 115. JXTG should do something similar.
Vadim
[1]
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/java/org/apache/cocoon/generation/ServerPagesGenerator.java?annotate=1.1
Re: Caching JXTemplate
Leszek Gawron wrote:
Unico Hommes wrote:
Unico Hommes wrote:
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
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:
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
wdyt?
Yes, I agree it would be better not to check each element for these
attributes. 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.
src/blocks/xsp/samples/java/cacheable.xsp:
/**
* Generate the unique key for the cache.
*
* This key must be unique inside the space of this XSP page, it is
used
* to find the page contents in the cache (if getValidity says that
the
* contents are still valid).
*
* This method will be invoked before the getValidity() method.
*
* @return The generated key or null if the component
* is currently not cacheable.
*/
public Serializable getKey()
{
// for our test, pages having the same value of "pageKey" will
share
// the same cache location
return "" + request.getParameter("pageKey");
}
That is why I thought the key is considered only in one page space. Is
this example broken ?
Don't know, maybe XSP generator augments that key with the uri of the
XSP source before it returns it to the pipeline If not, then the comment
that the 'key must be unique inside the space of this XSP page' is not
correct.
--
Unico
Re: Caching JXTemplate
Unico Hommes wrote:
Unico Hommes wrote:
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
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:
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
wdyt?
Yes, I agree it would be better not to check each element for these
attributes. 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.
src/blocks/xsp/samples/java/cacheable.xsp:
/**
* Generate the unique key for the cache.
*
* This key must be unique inside the space of this XSP page, it is used
* to find the page contents in the cache (if getValidity says that the
* contents are still valid).
*
* This method will be invoked before the getValidity() method.
*
* @return The generated key or null if the component
* is currently not cacheable.
*/
public Serializable getKey()
{
// for our test, pages having the same value of "pageKey" will share
// the same cache location
return "" + request.getParameter("pageKey");
}
That is why I thought the key is considered only in one page space. Is this
example broken ?
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Caching JXTemplate
Unico Hommes wrote: Unico Hommes wrote: I am carrying this over to dev@ so other developers can comment. Leszek Gawron wrote: Unico Hommes wrote: 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: 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 wdyt? Yes, I agree it would be better not to check each element for these attributes. 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 ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Caching JXTemplate
Unico Hommes wrote: I am carrying this over to dev@ so other developers can comment. Leszek Gawron wrote: Unico Hommes wrote: 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: 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 wdyt? Yes, I agree it would be better not to check each element for these attributes. 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. -- Unico
Re: Caching JXTemplate
I am carrying this over to dev@ so other developers can comment. Leszek Gawron wrote: Unico Hommes wrote: Unico Hommes wrote: Antonio Gallardo wrote: Upayavira dijo: Antonio Gallardo wrote: Upayavira dijo: Alan wrote: I'm wondering if there is a way to cache JXTemplate, or any ordinarily uncachable pipeline, maybe from flowscript, by teling Cocoon that for this URL this pipeline will not change. I have a JXTemplate that generates some XML based on request parameters, and for a given query string, it will always produce the same XML output. Thank You. JXTemplateGenerator in CVS is cachable now. See: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108607750303449&w=2 for the original 'spec' that is what I believe has been implemented. Hi: In the CVS the JXTG includes a patch that cache the compiled JXTG source. That way a second run is only interpreted. Before the patch JXTG compiled and then interpreted the JXT source file. Is this what you are expecting? This is not what I was suggesting. The patch that I understand has been made allows the caching system to decide whether or not to cache the page. Hence, generation is avoided completely if necessary (of course the page needs to be interpreted to identify the caching details, but much less work is required than if full generation takes place. I am not sure if this was coded after the discussion. Can you provided info about the status of that? Surely you couldn't have missed it. You committed it: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/JXTemplateGenerator.java?r1=1.46&r2=1.47 Now reviewing the patch, I can't imagine how this is going to work. Both cache key and validity objects that are passed in via the context seem to be returned without augmenting them. AFAICS they should be combined with a key identifying the src of the generator and the validity of that src respectively in order to work. 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: 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 wdyt? Yes, I agree it would be better not to check each element for these attributes. sounds like a good option to me. -- Unico
