Re: JXTG and caching - IT'S DONE

[Leszek Gawron <lg...@mobilebox.pl>]

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

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

-- 
Leszek Gawron                                      lgawron@mobilebox.pl

Re: JXTG and caching - IT'S DONE

[Leszek Gawron <lg...@mobilebox.pl>]

Upayavira wrote:
> 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?]
The parsed template model is being put into "local" cache - a map. That 
should go to transient store - I do not know the purpose of current 
solution.

> I would suggest:
> (a) patch the JXTemplateGenerator itself, rather than creating a new class.
Sure, this is what I am about to do. I just prepared the initial version 
that does not affect any existing sources.

> (b) Post this as a patch to Bugzilla. Then, hopefully someone'll get the 
> chance to check it and commit it.
OK

One more thing: The jx transformer will never be cacheable - not possible.

	LG

Re: JXTG and caching - IT'S DONE

[Upayavira <uv...@upaya.co.uk>]

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
>