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
