You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Rich Feit <ri...@gmail.com> on 2006/12/01 18:07:26 UTC
Re: request attribute issues for BEEHIVE-1031
Carlin,
Sorry for the long delay. Couldn't the implementation for the
reconstructible ModuleConfig live in the pageflow package? In general,
where is it created?
Rich
Carlin Rogers wrote:
> 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 <ca...@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 <ca...@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 <ri...@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 <ri...@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 <ri...@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 <ca...@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 <ch...@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 <ca...@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
>> > > >> >> >> > >
>> > > >> >> >> >
>> > > >> >> >>
>> > > >> >> >
>> > > >> >>
>> > > >> >
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: request attribute issues for BEEHIVE-1031
Posted by Carlin Rogers <ca...@gmail.com>.
Rich,
Thanks for the reply. In SVN revision 476221 I just added
ScopedRequest.getNamesOfRemovableAttributes() returns names of
attributes that do not need to be saved and left it at that for now.
I did look at having the implementation of the reconstructable
ModuleConfig could live in the page flow package. This would
definitely require doing more along your original design of having the
pageflow code set/mark the reconstructable attribute in the scoped
request. I was really trying to keep this simple and have the logic
and implementation just part of scoping. I can take a look at this
some more later.
Thanks again,
Carlin
On 12/1/06, Rich Feit <ri...@gmail.com> wrote:
> Carlin,
>
> Sorry for the long delay. Couldn't the implementation for the
> reconstructible ModuleConfig live in the pageflow package? In general,
> where is it created?
>
> Rich
>
> Carlin Rogers wrote:
> > 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 <ca...@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 <ca...@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 <ri...@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 <ri...@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 <ri...@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 <ca...@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 <ch...@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 <ca...@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
> >> > > >> >> >> > >
> >> > > >> >> >> >
> >> > > >> >> >>
> >> > > >> >> >
> >> > > >> >>
> >> > > >> >
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
>