Jacopo Cappellato wrote:
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.
I'd like to use a complex/specialized key (a custom class with a
Comparator) composed by:
* screen name and screen location
* (a subset of) input parameters map (input context)
Then I'd like to implement some utils method that allow to clear all the
cache entries associated to a given screen name and screen location.
This is interesting... but wouldn't it be more flexible and easier to implement
if we had one cache per screen (just like we do with entities)? I don't think
we'll ever have so many screens cached (ie into the hundreds) that this will
become unwieldy, and if it does happen then we can enhance the cache management
screens in webtools to better handle this.
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.
That is a good point.
One doubt I have, if we cache html output, is how to handle links with
session id information in them (for example when cookies are
disabled)... this would make the cache useless.
Ouch, that's a good one...
Actually, in order for this to work the cached screen couldn't have anything
request or session specific in it. This is a trick because the request and
session objects will typically be in the context and may be used in the
rendering of the screen. We'd probably have to remove those from the copy of
the context that is used for the unique identifier creation.
That could get a little messy. For this particular issue we can probably make
sure the jsessionid is never added, though that may cause problems
transitioning from/to HTTP to/from HTTPS in some browsers.
Yeah, that's a rough one... no really good solution is hitting me for that.
What is hitting me is that we're likely to run into other things like that... :(
-David
