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 Tue, 17 Oct 2006 21:53:42 GMT
I don't know if we can just assume that everything gets dropped. What
if a page flow developer has code that adds an attribute to the
request during the action and expects to see it during the rendering.
I think the portal framework view is that there are a subset of
attributes that do not need to be persisted, a set that are
reconstructable, and a set that probably need to be persisted
(including some of that they've added to the request) as is.

I think the form bean object is one we want to preserve as is. If we
just give a list of the attributes we think are OK to remove, then the
form bean object would still be in the attribute map persisted in the
session, without other logic to track form beans.

Seem OK?

Carlin

On 10/17/06, Rich Feit <richfeit@gmail.com> wrote:
> Great -- my only question is, why expose anything like
> getRemovableAttributeNames()?  Can't we just assume that everything gets
> dropped except the attributes we expose as reconstructible?
>
> Oh, one other detail I thought of this morning.  For the case where the
> user has returned to a page with validation errors, the form bean object
> in the request might be something we want to preserve across refresh
> requests.  Otherwise, the user's original form input values will be
> lost.  If we wanted to handle this, our return values from
> getReconstructibleAttributeNames() would just be more dynamic (we'd have
> to keep track of which form beans got put into the request).  What do
> you think?
>
> Rich
>
> Carlin Rogers wrote:
> > Yes, this sounds right. I agree that the "portal framework should be
> > in complete control of the actual storing and restoring of the
> > attribute values."
> >
> > The one other thing to mention in what the portal framework would do,
> > is the request to get the names of the attributes that do not need to
> > be stored or reconstructed (like the implicit objects we set in the
> > PageFlowPageFilter).
> >
> > So to recap and make sure we're on the same page for the design, the
> > ScopedRequest interface would have new methods...
> >
> > /**
> > * names of attributes that do not need to persist for a refresh request.
> > */
> > public List getRemovableAttributeNames();
> >
> > /**
> > * names of attributes that can be reconstructed.
> > */
> > public List getReconstructibleAttributeNames()
> >
> > /**
> >  * Returns a ReconstructibleAttribute that can reconstruct
> > * its original value.
> > */
> > public ReconstructibleAttribute getReconstructibleAttribute(String name)
> >
> > Sound good? Appreciate all the input.
> >
> > Carlin
> >
> > On 10/16/06, Rich Feit <richfeit@gmail.com> wrote:
> >> First, I'm assuming this is mainly framework feature, and that portlet
> >> developers would only rarely need to interact with it directly.  It's
> >> just so that NetUI can make a few attributes live across portal refresh
> >> requests.  Do you agree?
> >>
> >> Assuming that's true, here are some thoughts:
> >>
> >>   - I think your simpler approach of keeping a list of reconstructible
> >> attributes is a good one.
> >>
> >>   - Along the lines of what Chad said below, I think NetUI should be
> >> able to return a small object (state+logic necessary for reconstructing
> >> later) for all attributes returned in the list above:
> >>         ReconstructibleAttribute getReconstructibleAttribute(String
> >> attributeName);
> >>      The returned object could reconstruct the original attribute on
> >> demand:
> >>         Object originalValue =
> >> reconstructibleAttribute.reconstruct(<context>);
> >>      Assuming we have a factory for producing these things, we could
> >> allow the advanced user to override it in beehive-netui-config.xml.
> >>
> >>   - The portal framework should be in complete control of the actual
> >> storing and restoring of the attribute values -- our code should not do
> >> this.  It was a mistake (my mistake) to take on this responsibility in
> >> the first place -- it doesn't belong in NetUI.
> >>
> >>   - NetUI's only responsibility should be to provide a list of attribute
> >> names and the ability to get the small reconstructible attribute
> >> object.  The portal framework would:
> >>         1) at the end of a request, get the list of reconstructible
> >> attributes, call getReconstructibleAttribute() for each one, and  store
> >> the returned ReconstructibleAttributes in any way it chooses (RA is
> >> Serializable of course).
> >>         2) at the beginning of the next request, retrieve all of the
> >> ReconstructibleAttributes, reconstruct the original values, and set them
> >> in the request using setAttribute.
> >>
> >>   - Everything should be structured to make persisting attributes *not*
> >> the default.
> >>
> >> What do you think?
> >>
> >> Rich
> >>
> >> Chad Schoettger wrote:
> >> > 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