beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chad Schoettger" <chad.schoett...@gmail.com>
Subject Re: request attribute issues for BEEHIVE-1031
Date Mon, 16 Oct 2006 22:28:37 GMT
If a user wanted to drop some of the removable attributes to save
space, the caller would get the list of removable attributes from the
ScopedRequest then call dropAttribute() for those attributes.

If at that point the user invoked ScopedRequest.getAttributeMap() the
attributes which where dropped would not be in the map returned.

In order for the ScopedRequest to be able to reconstruct the
reconstructable attributes, it would be necessary to store the
information necessary to reconstruct in the attribute map.  This would
be returned by the ScopedRequest.getAttributeMap() but would have
'internal' key names and be much smaller in size that the original
attribute value.

 - Chad











On 10/16/06, Carlin Rogers <carlin.rogers@gmail.com> wrote:
> 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