Apply cache in services or entityes
2007/7/17, Adrian Crum <[EMAIL PROTECTED]>:
I think caching the widgets themselves might offer an improvement. I have no
opinion on the other items.
-Adrian
Jacopo Cappellato wrote:
> 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
>
>
