David,
David E Jones wrote:
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.
Are you saying that we should maintain *one* cache for each screen
name/location and associated to it a set of input context/output pairs?
For example, considering the productDetail screen:
the cache would be associated to:
some_location#productDetail
and associated to this cache will have many pairs, one for each
different input context:
productDetailUri?productId=WG-1000 (key) --> html detail screen for WG-1000
productDetailUri?productId=WG-1111 (key) --> html detail screen for WG-1111
...
It would be fine for me: I still need to study how the OFBiz cache
classes are organized, so I am probably missing your point, sorry.
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.
Yes, we will have to remove some stuff (or just ignore it in the custom
Comparator), for example the nowTimestamp, etc...
But the decision will be difficult for some variables: for example,
should we ignore the userLogin object? If we consider it then the screen
cache will be only useful for anonymous users; if we ignore it then we
could miss important information (prices specific for a customer etc...)
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... :(
That is exactly what is worring me...
Jacopo
-David
