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 Fri, 01 Dec 2006 17:07:26 GMT
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 <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