cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: JXTG and caching
Date Tue, 01 Jun 2004 09:04:41 GMT
Leszek Gawron wrote:

> Sylvain Wallez wrote:
>
>> Well, it _could_ have a chance to work, but flowscript is definitely 
>> not the appropriate location to compute cache information for an 
>> element of the view pipeline.
>
> not the appropriate .. but really there is no other place ..
>
>> The problem with JXG is that the template is the generate() method 
>> _only_ whereas an XSP is the full class, allowing to define getKey() 
>> and getValidity().
>>
>> So what about adding two optional attributes on the template's root 
>> element, defining the cache information?
>>
>> <page
>>    xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
>>    jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
>> cocoon.request.get("bcd")....'
>>    jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
>>    ... template ....
>> </page>
>>
>> WDYT?
>
> Fine for simple cases but limits of this solution will appear very fast.
> I just know what would users do (what I would also do if I wanted 
> something more complex)
>
> the .js file:
>
> function validityForView() {
>   var validity = new SomeVeryHardToComputeInOneLineValidity();
>   return validity;
> }
>
> function keyForView() {
>   var key = someVeryStrangeKeyFetchedFromSomewhere;
>   return key;
> }
>
> function showSomeView() {
>   cocoon.session.setAttribute( "myViewValidityFunc", validityForView );
>   cocoon.session.setAttribute( "myViewKey", keyForView );
>   cocoon.sendPage( "view/myview.jx", {} );
> }
>
> the template:
> <page
>    xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
>    jx:cache-key='${cocoon.session.myViewKey()}'
>    jx:cache-validity='${cocoon.session.myViewValidityFunc()}'>
>    ... template ....
> </page>


Well, although not the nicest construct, I still prefer it to the one 
you initially proposed, as the cache information is still triggered by 
the generator, even if the corresponding code is in the flowscript.

> This and other examples proove that we need a way to extend jxtemplate 
> generator with flow functions (or other logic "providers") when simple 
> macro is not enough. This may lead to a jsb taglib nightmare but hey: 
> user has got his own brain not to put database inserts in there and if 
> he is he's just asking for troubles.
>
> I still do not understand why we do have jx:formatDate and 
> jx:formatNumber which are just some instances of formatters while 
> there either should be none at all or just pluggable ones.


<snip/>

I totally agree with you. The <jx:macro> is good for simple cases, but 
we need taglibs à la XSP or Jelly.

I actually do think that the JX language can be rewritten as a Jelly 
taglib. Any taker?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message