beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: request attribute issues for BEEHIVE-1031
Date Tue, 17 Oct 2006 22:06:10 GMT
I think that the portal framework should actually be the one to decide, 
and that we should be exposing the attributes that we think are 
necessary to reconstruct.  A portlet could even be configured for 
keep-all-attributes or only keep-necessary-attributes (or even 
keep-no-attributes).  In this case I guess we might want to expose a 
list of attributes that *must* be dropped, which is more along the lines 
of what you're suggesting.

I wonder if we've been talking about two different things:
    - attributes which can be reconstructed, even if they're not 
directly Serializable
    - attributes which really should be carried across refresh requests, 
like action outputs

I've been thinking of it as the latter -- how about you?

Rich

Carlin Rogers wrote:
> 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