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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/[EMAIL
PROTECTED]
> > >>
> > >> >>
> > >> >> >>
> > >> >> >> > > 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
> > >> >> >> > >
> > >> >> >> >
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >
> > >>
> > >
> >
>
