cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: JXTG and caching
Date Tue, 01 Jun 2004 13:20:45 GMT
Sylvain Wallez wrote:
> Leszek Gawron wrote:
> 
>> While almost everybody buried XSP it has got one great feature that 
>> JXTG  lacks: it's cacheable. I know that there is no way to implement 
>> automatic JXTG caching but what if I know on what env does jx template 
>> operate. If I know that it is for example only request param "abc" and 
>> "bcd" and session attribute "xxx" then I know when I can use cached 
>> entry. The question is: how?
>>
>> Should I extend JXTemplateGenerator so it is a cached component? I 
>> understand it gets the validity methods to implement then. So every 
>> time I call my extended component from flow I pass also the validity 
>> calculated in flow. Something like this:
>>
>> function niceCachedResponse() {
>>   var cacheKey = cocoon.request.get( "abc" ) + "!!spacer!!"
>>                     + cocoon.request.get( "bcd" ) + "!!spacer!!"
>>                     + cocoon.session.getAttribute( "xxx" );
>>   var pageValidity = new DeltaTimeCacheValidity( 60 * 60 * 24 );
>>                                                 // one day
>>   cocoon.sendPage( "view/cached.jx", {
>>                                      JXTGExtCacheKey: cacheKey,
>>                                      JXTGExtpageValidity: pageValidity
>>                                      someOtherBizData: data } );
>> }
>>
>> Does it have a chance to work ?
> 
> 
> 
> 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.

I started to implement the functionality we discussed but then it hit me: it's 
completely useles for my case. Look at this:

function showData() {
   var bizData = {};
   bizData[ "pageData" ] = fetchBizDataByHeavyDBRetrieval();
   var validity = cocoon.createObject( DBViewValidity );
   bizData[ "cacheingInfo" ] = validity;
   cocoon.sendPage( "view/someview.jx",
                    bizData,
                    function() {
                      cocoon.releaseObject( validity );
                    } );
}

What is the point of implementing caching control in JXTG in this case if I do 
  "heavy db retrieval" anyway.

CachingJXTG is good here only for those cases which in which one can omit 
bizData preparation.

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.
	LG
-- 
Leszek Gawron

Mime
View raw message