On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres <[EMAIL PROTECTED]> wrote: > The dangerous case is when you add to the value stack objects with > some identical properties, that's when the order in the stack is > important (and should log a warning when this happens?). If there are > no objects with shadowed properties, then it should be ok?
In the case of validation, doesn't that happen in the normal course? Don't we push the validator property onto the stack, so that we can capture whatever String value is input, even if it is not valid for a binary type (e.g. "blue" for an int type)? -Ted. On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres <[EMAIL PROTECTED]> wrote: > I'm not a big user of ModelDriven, but reading the > ModelDrivenInterceptor source code I see what you meant. > > I thought that making an action ModelDriven would push the model at > the top of the stack, but it seems that there are cases where the > pushed model will not end at the top of the value stack when the > result is rendered. > Can this be cases where this may happen: > when action-chaining the result to another ModelDriven action? what if > both actions has refreshModelBeforeResult==true? > when other interceptor pushes data after the ModelDriverInterceptor? > > The dangerous case is when you add to the value stack objects with > some identical properties, that's when the order in the stack is > important (and should log a warning when this happens?). If there are > no objects with shadowed properties, then it should be ok? > > > 2008/7/16 Dave Newton <[EMAIL PROTECTED]>: >> --- On Wed, 7/16/08, Gabriel Belingueres wrote: >>> May you describe us a context, a use case, UI interaction or >>> the sequence of events that need to take place so that would >>> you be exposed to this behavior? >> >> Any time there's stack manipulation and the user accesses the stack via >> OGNL's [] syntax. >> >> Like I said, it's an edge case, but it's a case nonetheless. >> >> 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] > > -- HTH, Ted http://husted.com/ted/blog/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
