Perhaps, instead of output caching to memory, output to a "temporary" contentId and store the output to disk or to xml database?
--- BJ Freeman <[EMAIL PROTECTED]> wrote: > seems that the processing of the key would take up a lot of memory > and > time to process, assuming that 90% of the widgets were cached. > > > Jacopo Cappellato sent the following on 7/17/2007 8:32 AM: > > Hi all, > > > > I'd like to discuss with you all about the idea of implementing > screen > > widget output caching. > > > > Goal: minimize the db/service hits for rather static screens (for > > example a category or product detail screen in the ecommerce); this > > could be done by implementing screen widget output caching that > prevents > > the screen widget actions (and possibly ftl) from running > > > > Draft/proposal for implementation: > > > > a) add new attributes in the screen definition for cache settings > (e.g. > > cache="true|false" etc...) > > b) the cache key can be derived from the screen name and the > > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > > represents the input context for screens > > c) associated to the cache key we will cache the final output of > the > > screen (html code or xsl-fo code...) > > d) if the cache is enabled for a given screen, the input > "parameters" > > map is used as a key for the cache system, if no value is found, > then > > the screen (actions + froms + ftl templates) is run as usual and > the > > output is rendered and stored in the cache (with key screen name + > > "parameters"); if the value is found, then the output is retrieved > from > > memory and sent to the user (no actions and ftl are executed) > > > > A different option would be that of storing the output context in > the > > cache and serve it to the ftl (instead of storing the output > html/xsl-fo). > > > > I'd love to get your feedback about this, ideas/concerns, > > > > Jacopo > > > > > > > > >
