Re: JXTG and caching

[Sylvain Wallez]

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 }