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, 07 Nov 2006 00:39:01 GMT
Hey Rich,

I was looking at this a bit more today and hit a bit of a snag. I've
been thinking that the implementation of a given
ReconstructableAttribute would contain the knowledge or how to
reconstruct the given attribute type it handles, such as a
ModuleConfig. For example, the implementation for reconstructing the
ModuleConfig attribute would call PageFlowUtils.ensureModuleConfig().
However, that would mean a dependency of the scoping package on the
pageflow package. We've been very careful to avoid creating this
dependency in the past and having a cyclic dependency in the build.
Any thoughts?

Thanks,
Carlin

On 10/24/06, Carlin Rogers <carlin.rogers@gmail.com> wrote:
> Rich,
>
> ...also, in an earlier post I made the comment about these methods
> being on the ScopedRequest. Seems like the best place. However,
> ScopedRequest is an interface so to avoid API issues, I think the
> changes might need to be in the ScopedServletUtils. Or, could it be in
> a release note since the general page flow app developer would not use
> this. What do you think?
>
> Thanks,
> Carlin
>
> On 10/17/06, Carlin Rogers <carlin.rogers@gmail.com> wrote:
> > Yes, I agree, we want the portal framework to decide what attributes
> > to persist. I've been looking at it from the point of view that a
> > framework wants to reduce or optimize the size of the user session.
> > I.E., What's required to successfully do a refresh request to each
> > individual portlet.
> >
> > From the ScopedRequest attribute map, there are some NetUI attributes
> > that are no longer needed for the refresh... drop them. But how does a
> > portal know what these are? And if they do, they can't just use our
> > attribute names because they are not public.
> >
> > Then there are the set of NetUI attributes that should be restored on
> > the refresh request. Some of these are small (String or Boolean) such
> > as the attribute that indicates to NetUI that it has saved the
> > previous page info (for NavigateTo). These should just be saved. No
> > need to reconstruct. Other attributes are the action outputs you
> > mention. Within this set of attributes are two that can be
> > reconstructed (I don't know of any others), the module config and
> > action mapping.
> >
> > From a framework point of view, there's a attribute map for the scoped
> > request with NetUI, portal, and maybe developer attributes. I guess I
> > don't see how they know which attributes a portal/app developer has
> > created and should be saved versus which ones are NetUI attributes
> > that can be removed. Providing the name of attributes that are safe to
> > remove seems to solve this issue.
> >
> > Again, thanks for all your feedback.
> > Carlin
> >
> > On 10/17/06, Rich Feit <richfeit@gmail.com> wrote:
> > > 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