Leszek Gawron wrote:
Upayavira wrote:
It seems to me that Sylvains suggested extension of jxt has a great deal of power in it.
OK. Then I'll continue my work and try to provide the appropriate patch as I have already started to make needed changes.
Great. I'd love to see a cacheable jxt.
Regards, Upayavira
You can test the first implementation if you fetch this file : http://ouzo.wlkp.org/cjxtg.zip
Fab.
The below all reads okay to me. It would seem reasonable that the template must be read in setup now. [As an aside, is the jxt file cached? Or does it need to be read with every request? Maybe the parsed jxt could be put into the transient store or something?]
I would suggest:
(a) patch the JXTemplateGenerator itself, rather than creating a new class.
(b) Post this as a patch to Bugzilla. Then, hopefully someone'll get the chance to check it and commit it.
Regards, Upayavira
it contains :
CachingJXTemplateGenerator.java which you should put to the same directory as JXTG.java and rebuild your cocoon.
There also is a simple test case in test directory. Put it into your webapp root and then issue this url:
http://localhost:8888/test/test.do?key=<something>
if I got it right the view is generated once for each key and cached so the date on the page won't change if you refresh your page.
How it works:
1. every attribute in "http://apache.org/cocoon/templates/jx/1.0"; namespace get stripped from attributes and end up in StartDocument event in templateProperties map (which I added). This is something that could be used for providing additional parameters to template in the future.
These attributes are not generated to output. They are only stored in map. This was the simplest solution. I think it's acceptable. How about you?
2. In template's root element (or any element really) you put:
<page jx:cache-key="${biz.getKey()}" jx:cache-validity=${biz.getValidity()}">
The key should be Serializable and the Validity should be SourceValidity of course.
Voilla .. the page gets cached.
What changed:
1. CachingJXTemplateGenerator implements CacheableProcessingComponent
of course :)
2. StartDocument.templateProperties added
3. I had to move template parsing from generate to setup(). Otherwise that happened:
- fetch http://localhost:8888/test/test.do?key=abc - setup() called - getKey() called - template not parsed yet, cannot compute key - no view caching will be done - generate() - template gets parsed and generated, template cached - refresh browser - setup() called - getKey() - got parsed template, can evaluate cache-key - lookup from cache fails as the first response was not cached - generate() - template already parsed - response cached, getValidity() called somewhere of course
The response gets cached after second page hit because getKey() first time is called before template is parsed. When parsing is moved to setup() this happens:
- fetch http://localhost:8888/test/test.do?key=abc - setup() called, template gets parsed - getKey() called, template accessible, key computed - cache lookup falils - generate() called - response cached!
This class can become standard JXTemplateGenerator as if you do not provide caching attributes the page never gets cached so it works like it did before.
Please make your comments
