Pushed properties don't have names, just positions, AFAIK.
If you look at the code for ModelDrivenInterceptor my original reply might make
more sense.
Dave
--- On Thu, 7/17/08, Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> From: Gabriel Belingueres <[EMAIL PROTECTED]>
> Subject: Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
> To: "Struts Developers List" <dev@struts.apache.org>, [EMAIL PROTECTED]
> Date: Thursday, July 17, 2008, 9:08 AM
> The map would be just an auxiliary data structure to
> maintain this
> propertyName -> ownerObject mapping (I suppose you could
> just iterate
> on every object in the stack using reflection to ask about
> its
> properties, or some fancy method in commons-beanutils
> library) but the
> general idea is the following:
>
> Suppose you have in the stack an Employee object which has
> a name
> property (with its getter/setter). The Employee has pushed
> by some
> interceptor in the interceptor chain. The Map would hold
> the
> ("name"->employee) mapping.
>
> Suppose you have a ModelDriven action that returns in the
> getModel()
> method a Person object, which too has a name property. Now
> when the
> interceptor tries to push into the stack, the stack first
> check if the
> properties of this object is already in the map. Because
> they share a
> name property, you can warn the user that you are shadowing
> then name
> property of the employee object.
>
> Of course this checking would belong inside the ValueStack,
> not in the
> ModelDriverInterceptor.
>
>
> 2008/7/17 Dave Newton <[EMAIL PROTECTED]>:
> > --- On Wed, 7/16/08, Gabriel Belingueres
> <[EMAIL PROTECTED]> wrote:
> >> I believe that we could check on stack.push() if
> the object
> >> to push shadows some other object in the stack
> with relative ease.
> >>
> >> The basic idea would be to use a
> Map<String,Object>
> >> where the key is the property name, and the value
> is
> >> the object in the stack with that property name.
> If
> >> the yet to push object has a property that is
> already
> >> in the Map, then it would shadow it (unless of
> course
> >> it is actually the same object), and a warn can be
> >> logged/exception thrown (in devMode only).
> >
> > You lost me--why would we need to keep a shadow map?
> >
> > The current code checks if a refresh is needed: if it
> is, the old object is removed via ArrayList.remove(Object),
> and if appropriate, the new object is pushed (the stack
> order change).
> >
> > To replace the old object ArrayList.indexOf(Object)
> would retrieve the index and the new object would be set
> with ArrayList.set(int, Object).
> >
> > There's still a potential stack depth issue,
> though, since if the new value is null it's not
> supposed to get put on the stack.
> >
> > Dave
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
