After taking a look at this issue as well, I'm in agreement with
adding a new method to the ScopedRequest which returns a list of NETUI
attribute names that don't need to be persisted in a session.
I was thinking for attributes which can be reconstructed, that instead
of adding any new API's to the ScopedRequest, the ScopedRequest would
reconstruct those values internally the next time the ScopedRequest
getAttribute() method is invoked for that reconstructable attribute
value.
Something like:
ScopedRequest
getAttribute(String attributeName) {
.
.
.
if (!attributeName in map) {
if (isReconstructable(attributeName)) {
return reconstructAttribute(attributeName);
}
}
.
.
.
}
Using this approach would seem to simplify what a portal developer
needs to do in order to use this feature.
- Chad
On 10/15/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
I'm looking at BEEHIVE-1031 (been on my plate for a while now) and
some of the information already discussed. I have a couple of thoughts
and wanted to get your feedback. Chad has taken a look at this as well
so he may have some ideas or input.
Rich posted some good initial design thoughts to the dev list and a
wiki page a while ago...
http://mail-archives.apache.org/mod_mbox/beehive-dev/200509.mbox/[EMAIL
PROTECTED]
http://wiki.apache.org/beehive/Design/PortletScoping
(start at the 3rd paragraph in "Issues and Future Directions" of the wiki page)
Here's a slightly different approach... In much of the NetUI code we
do not know that we have a scoped request when we set an attribute.
Rather than change the NetUI code to setPersistableAttribute and
markPersistableAttribute, how about just having a simple ScopedRequest
method that returns a list of NetUI attribute names that don't need to
be persisted in a session for use in a refresh request. A portal
framework can use this list of names to remove attributes from the set
to be saved in the session. Most of the objects that do not need to be
persisted for a refresh request are the ImplicitObjects that get
loaded when a request goes through the PageFlowPageFilter.
I think there are just two attributes that would fall into the
re-constructable category; the module config and the action mapping
instance. For these, NetUI could still implement something like what
Rich suggested to allow portal developers to reduce the size of the
attribute objects persisted in the session.
The ScopedRequest could have a method to return a map of
reconstructable attributes. This would provide portal framework
developers the option of using these reconstructable attributes to
persist in the session in place of the true attributes from the
ScopedRequest atttribute map. The ScopedRequest could also have a
method to provide the names so on a refresh request the framework
would know what attributes to reconstruct from the persisted set in
the session, before restoring the attribute map for a ScopedRequest.
Thoughts?
Thanks,
Carlin
