beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <carlin.rog...@gmail.com>
Subject Re: request attribute issues for BEEHIVE-1031
Date Mon, 16 Oct 2006 20:24:58 GMT
Thanks for the feedback Chad. I have a question about how NetUI should
handle the ScopedRequest.getAttributeMap() / setAttributeMap() if the
ScopedRequest implementation is handling the reconstruction of
attributes. The portal framework uses these two methods when managing
the persisted attributes.

Would getAttributeMap() always return a map that contained the
reconstructable attributes or the true attributes? I'd think we'd want
the reconstructable attribute objects. Then a caller could get the set
of reconstructable attributes and go through the dropAttribute(), and
a later call to setAttributeMap() for a refresh request would return
the reconstructable attribute objects to the request. And as you have,
a follow up call to getAttribute() would reconstruct it. Is that
correct?

Other thoughts?

Carlin

On 10/16/06, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> 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 <carlin.rogers@gmail.com> 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/%3c43209239.3030502@gmail.com%3e
> > 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
> >
>

Mime
View raw message