Re: JXTG and caching

[Upayavira]

Leszek Gawron wrote:
Replying myself :)
Leszek Gawron wrote:
It would have to look somewhat like this:
function showData() {
  var validityKey = "request-param:a!!spacer!!request-param:b";
  var pipeline = "view/someview.jx"
  if ( someCacheManager.isValid( pipeline, validityKey ) ) {
    // hope the cache entry does not expire between isValid and page
    // generation
    var dummyBizData = {};
    cocoon.sendPage( "view/someview.jx", dummyBizData );
    return;
  }
  // the page is not cached
  // do the heavy processing here and send new page
  var bizData = {};
  bizData[ "pageData" ] = fetchBizDataByHeavyDBRetrieval();
  var validity = cocoon.createObject( DBViewValidity );
  bizData[ "cacheingInfo" ] = validity;
  cocoon.sendPage( "view/someview.jx",
                   bizData,
                   function() {
                     cocoon.releaseObject( validity );
                   } );
}
It does not look like SoC.
It does not look like it is possible to implement either if you take 
aggregated views into account - one part of the view might need 
rendering because it expired while other could still be fetched from 
cache. Controller would have to know what parts is the view build of 
and generate appropriate data which breaks SoC completely.

The conclusion is: the only way we can generate a cached view is to 
use some technlogogy that "pulls" data (like a java generator or XSP). 
While xsp is not considered a good practise nowadays it needs a 
replacement fast.

JXTG could be made cacheable for simple cases - ones that do not need 
heavy bizData preparation. Still JXTG gets data pushed into which 
needs prior data retrieval. In cases when data preparation is much 
more resource consuming than view rendering caching hardly makes sense.
I think you are getting something wrong here.
If you have two objects bizObj1 and bizObj2, and you pass these to a 
pipeline that does

JXT(bizObj1)->tx->tx-\
                     >-aggregate->tx->serlialize
JXT(bizObj2)->tx->tx-/
You would do:
sendPage("your-pipeline", {"bizObj1": bizObj1, "bizObj2": bizObj2});
Then, your objects would implement:
bizObj.getValidity()
And the jxtemplate would ask the business object for its validity as 
Sylvain has described.

Thus, if bizObj1 says it can be cached, and bizObj2 says it can't, then 
at least one of your two aggregated pipelines doesn't need to be 
generated, which will speed up processing.

Remember, the jxtemplate pulls the validity from the business object. 
The flow doesn't need to even know that caching might be happening (and 
in fact _shouldn't_ know it is happening). If you have to write 
flowscript to deal with this, then something is probably wrong.

If your business object takes an age to instantiate, and you can decide 
whether or not to instantiate it based upon request parameters, then 
wrap it in a lighter component that does (in pseudocode):

lightObject.getValidity() {
 return request.parameters["a"]+ request.parameters["b"];
}
lightObject.getHeavyBusinessObject() {
 if (this.heavyBusinessObject == null) {
    this.heavyBusinessObject = HeavyBusinessObjectBuilder.newObject();
 }
 return this.heavyBusinessObject;
}
Then, in your jxt, you use Sylvains 
jx:cacheKey="lightObject.getValidity()" construct, and then later in 
your jxt, you access your heavy object with 
#{/lightObject/HeavyObject/property1}. This latter expression will only 
be invoked if the page is not cached.

Does that make sense?
It seems to me that Sylvains suggested extension of jxt has a great deal 
of power in it.

Regards, Upayavira