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 > > > >
