I think this is a great idea. As with any other caching tool it needs to be
used properly, and based on some of the responses there seems to be some
misunderstanding about that.
Just as with entity caches this would only be helpful for high volume screens
that are not updated frequently, and in many cases we would want to cache only
parts of high level screens, like the product information on the product detail
page, but not the mini cart or other sub-screens on the sides that are
user-specific.
Also when used this would be more susceptible to stale information as the only
easy mechanism for refreshing these is a time limit. We would probably want to
make it possible to specify the cache name to cache the screen in, or I guess
we could just have some convention (but it would result in long cache names to
have the location and screen name put together to make it unique). With this
and the caching infrastructure in OFBiz we could have size (number of elements)
limits, timeouts, soft references, etc to help manage the caches.
If we did something like this my vote would be on caching the entire output of
the screen. If someone wanted to speed up the data preparation chances are the
most effective way to do it would be to use the entity engine caches to help
with database round trip delays and such, which often takes up BY FAR the
majority of the data preparation time.
This sort of tool could be really nice but very complex if it had an auto-clear
mechanism like that of the entity engine, but for this sort of things it would
be REALLY hard to have some sort of change notification mechanism that is used
for as much of what goes into screen contexts as possible. Anyway, my point is
that it's probably not feasible to do this and we shouldn't worry about it
initially. The tool would have value with proper use even without that.
One thing about this, BTW: for screens that use all cached data retrieval it
would be interesting to time the difference in execution because as they are
now, these things run pretty fast. There would certainly be a difference, but
I'm wondering how much of an impact it might have. Still, for ecommerce and
content sites that are going through a million pages an hour, this sort of
feature could be the difference between using OFBiz and some other technology
entirely.
-David
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
