Eric,
Good questions...
Eric Dalquist wrote:
This sounds great, just the sort of thing I was hoping for with the
better caching backend.
A few questions:
1. How are the cache entries keyed?
By username, as it stands. I'm not aware of (1) a way that a single
user can have more than one layout loaded in memory, nor (2) a way that
multiple people can have the same username (in fact this situation would
wreak havoc).
2. Does this change the cached entry invalidation logic at all from the
existing code?
I don't think so, but perhaps I don't understand the question.
We're talking about caching the user's layout DOM, not a theme transform
or any rendered content.
The cache just replaces a private member variable, such that...
- any calls to getLayout() check the cache, but get it from the
layoutStore if it's not found
- any calls to setLayout() place a new copy in the cache
- any methods that previously set the layout to null would now call
cache.remove(username), which clears the way for getLayout() to pull
from the layoutStore on the next call the getLayout()
It *does* change the behavior of the portal in one, uncommon scenario:
it's possible that your layout can change while you're logged in
(without your direct manipulation), based on a fragment layout changing
or somesuch.
This possibility is considered desirable by some; those who consider it
undesirable would be able to configure the LAYOUT_CACHE in a manner that
would prevent it.
3. Does this also move the DLM fragment cache into a managed cache as well?
I wish.
The layouts of the actual user accounts that own the fragments would be
cached, but DLM uses a different data structure to store the
"fragmentized" layout objects it use to build composite layouts.
drew wills
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
