cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: JXTG and caching - IT'S DONE
Date Fri, 04 Jun 2004 15:05:33 GMT
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
>



Mime
View raw message