You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Dave Newton <ne...@yahoo.com> on 2008/07/16 20:24:32 UTC
Sanity-check regarding ModelDrivenInterceptor vs. stack order
I'm not sure if this is a potential issue or not, so wanted quick feedback before deciding if a minor documentation change is warranted.
It appears as though ModelDrivenInterceptor could change the stack order when a refresh is necessary; the old model is removed from wherever it was in the stack and the new model is simply pushed.
Is it worth mentioning?
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
--- On Thu, 7/17/08, Ted Husted <hu...@apache.org> wrote:
> Is the XWork source browsable online anywhere, or do we have
> to check it out?
It's browseable thru FishEye on the OpenSymphony site:
http://svn.opensymphony.com/fisheye/viewrep/xwork/trunk
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Ted Husted <hu...@apache.org>.
Is the XWork source browsable online anywhere, or do we have to check it out?
-Ted.
On Thu, Jul 17, 2008 at 9:19 AM, Dave Newton <ne...@yahoo.com> wrote:
> 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 <be...@gmail.com> wrote:
>
>> From: Gabriel Belingueres <be...@gmail.com>
>> Subject: Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
>> To: "Struts Developers List" <de...@struts.apache.org>, newton.dave@yahoo.com
>> 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 <ne...@yahoo.com>:
>> > --- On Wed, 7/16/08, Gabriel Belingueres
>> <be...@gmail.com> 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:
>> dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail:
>> dev-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
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 <be...@gmail.com> wrote:
> From: Gabriel Belingueres <be...@gmail.com>
> Subject: Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
> To: "Struts Developers List" <de...@struts.apache.org>, newton.dave@yahoo.com
> 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 <ne...@yahoo.com>:
> > --- On Wed, 7/16/08, Gabriel Belingueres
> <be...@gmail.com> 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:
> dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Gabriel Belingueres <be...@gmail.com>.
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 <ne...@yahoo.com>:
> --- On Wed, 7/16/08, Gabriel Belingueres <be...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
--- On Wed, 7/16/08, Gabriel Belingueres <be...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Gabriel Belingueres <be...@gmail.com>.
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).
2008/7/16 Dave Newton <ne...@yahoo.com>:
> --- On Wed, 7/16/08, Jeromy Evans wrote:
>> Is it possible to make it do a replace within the stack?
>
> The stack implementation is an ArrayList subclass, so I suppose it could do an indexOf/set (if the new model isn't null, anyway, in which case the stack could still change :/
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
Meant to attach my original pseudo-code, mostly for a laugh at my expense.
if (root.indexOf(newModel) < 0) {
if (originalModel != null) {
int originalIdx = root.indexOf(originalModel);
if (originalIdx >= 0) {
Object thanksJava = (newModel != null) ? root.set(originalIdx, newModel) : root.remove(originalIdx);
}
} else if (newModel != null) {
stack.push(newModel);
}
}
Then I decided to write it so I could actually understand it if I ever saw it again.
// New model already on stack; no refresh needed.
if (root.indexOf(newModel) >= 0) {
return;
}
// Original model was null; just push new model on stack
// (nothing to replace) if new model not null.
if ((originalModel == null) && (newModel != null)) {
stack.push(newModel);
return;
}
// Can't find original model on stack? Something may be wrong.
// TODO devMode exception.
int originalIdx = root.indexOf(originalModel);
if (originalIdx < 0) {
return;
}
// Replace if new model not null, otherwise remove original
// model--null models not put on stack.
if (newModel != null) {
root.set(originalIdx, newModel);
} else {
root.remove(orginalIdx);
}
Then I realized I might have a future as a botanist or something, because at this point in my day I can't tell if either is correct :/
Dave
--- On Fri, 7/18/08, Dave Newton <ne...@yahoo.com> wrote:
> --- On Thu, 7/17/08, Ted Husted <hu...@apache.org>
> wrote:
> > As mentioned, to refresh the model, we remove the
> existing
> > model and push the latest version. For a
> "refresh" operation,
> > we might expect the new instance to replace the old
> instance
> > in the same stack position.
> >
> > In RefreshModelBeforeResult, we already have a
> reference to
> > the old model ("Item"). Could we just
> replace one object
> > with another?
> >
> > for (Object item : root) {
> > if (item == newModel) {
> > needsRefresh = false;
> > }
> > + else {
> > + item = newModel
> > + }
>
> Would that replace every non-newModel item? Maybe something
> closer to this, using your code as a start, then ruining it
> with returns (it's late, I'm groggy :)
>
> boolean replaced = false;
> for (Object item : root) {
> if (item == newModel) {
> return;
> } else if (item == originalModel) {
> if (newModel != null) {
> item = newModel;
> } else {
> root.remove(item);
> }
> return;
> }
> }
>
> if (newModel != null) {
> stack.push(newModel);
> }
>
> The other issue I mentioned is that if newModel is null the
> current code doesn't push it--there's always a
> chance of the stack *depth* being modified, even if the
> stack index of the model isn't. This seems unavoidable
> and may not be an important issue.
>
> Hmm, if for some reason there were two instances of the
> model (maybe even original *or* new models?) on the stack
> there could be some confusion.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
--- On Thu, 7/17/08, Ted Husted <hu...@apache.org> wrote:
> As mentioned, to refresh the model, we remove the existing
> model and push the latest version. For a "refresh" operation,
> we might expect the new instance to replace the old instance
> in the same stack position.
>
> In RefreshModelBeforeResult, we already have a reference to
> the old model ("Item"). Could we just replace one object
> with another?
>
> for (Object item : root) {
> if (item == newModel) {
> needsRefresh = false;
> }
> + else {
> + item = newModel
> + }
Would that replace every non-newModel item? Maybe something closer to this, using your code as a start, then ruining it with returns (it's late, I'm groggy :)
boolean replaced = false;
for (Object item : root) {
if (item == newModel) {
return;
} else if (item == originalModel) {
if (newModel != null) {
item = newModel;
} else {
root.remove(item);
}
return;
}
}
if (newModel != null) {
stack.push(newModel);
}
The other issue I mentioned is that if newModel is null the current code doesn't push it--there's always a chance of the stack *depth* being modified, even if the stack index of the model isn't. This seems unavoidable and may not be an important issue.
Hmm, if for some reason there were two instances of the model (maybe even original *or* new models?) on the stack there could be some confusion.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Ted Husted <hu...@apache.org>.
+1
As mentioned, to refresh the model, we remove the existing model and
push the latest version. For a "refresh" operation, we might expect
the new instance to replace the old instance in the same stack
position.
In RefreshModelBeforeResult, we already have a reference to the old
model ("Item"). Could we just replace one object with another?
for (Object item : root) {
if (item == newModel) {
needsRefresh = false;
}
+ else {
+ item = newModel
+ }
* http://svn.opensymphony.com/fisheye/browse/~raw,r=1833/xwork/trunk/src/java/com/opensymphony/xwork2/interceptor/ModelDrivenInterceptor.java
Or would there be side-effects?
HTH, Ted.
On Wed, Jul 16, 2008 at 7:22 PM, Jeromy Evans
<je...@blueskyminds.com.au> wrote:
> Dave Newton wrote:
>>
>> It appears as though ModelDrivenInterceptor could change the stack order
>> when a refresh is necessary; the old model is removed from wherever it was
>> in the stack and the new model is simply pushed.
>>
>>
>
> Is it possible to make it do a replace within the stack?
>
> If not, rather than document it, I'd prefer that it throws an exception
> (stack order changed exception/model not at top of stack exception/something
> like that exception), so the developer's attention is drawn to it. These
> kinds of things cause apparently intermittent & difficult to isolate
> problems.
> The i18n tag had a similar issue when its closing tag liberally popped
> anything off the top of the stack (now throws)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
--- On Wed, 7/16/08, Jeromy Evans wrote:
> Is it possible to make it do a replace within the stack?
The stack implementation is an ArrayList subclass, so I suppose it could do an indexOf/set (if the new model isn't null, anyway, in which case the stack could still change :/
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Dave Newton wrote:
>
> It appears as though ModelDrivenInterceptor could change the stack order when a refresh is necessary; the old model is removed from wherever it was in the stack and the new model is simply pushed.
>
>
Is it possible to make it do a replace within the stack?
If not, rather than document it, I'd prefer that it throws an exception
(stack order changed exception/model not at top of stack
exception/something like that exception), so the developer's attention
is drawn to it. These kinds of things cause apparently intermittent &
difficult to isolate problems.
The i18n tag had a similar issue when its closing tag liberally popped
anything off the top of the stack (now throws)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Gabriel Belingueres <be...@gmail.com>.
I think I need to read more code to follow this thread...I promise.
2008/7/17 Ted Husted <hu...@apache.org>:
> On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres
> <be...@gmail.com> 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
> <be...@gmail.com> 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 <ne...@yahoo.com>:
>>> --- 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: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> HTH, Ted
> http://husted.com/ted/blog/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Ted Husted <hu...@apache.org>.
On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres
<be...@gmail.com> 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
<be...@gmail.com> 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 <ne...@yahoo.com>:
>> --- 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
http://husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Gabriel Belingueres <be...@gmail.com>.
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 <ne...@yahoo.com>:
> --- 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Dave Newton <ne...@yahoo.com>.
--- 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Gabriel Belingueres <be...@gmail.com>.
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?
2008/7/16 Musachy Barroso <mu...@gmail.com>:
> more details in the docs = less questions in the mailing list. Or not,
> but it helps ;)
>
> musachy
>
> On Wed, Jul 16, 2008 at 2:24 PM, Dave Newton <ne...@yahoo.com> wrote:
>> I'm not sure if this is a potential issue or not, so wanted quick feedback before deciding if a minor documentation change is warranted.
>>
>> It appears as though ModelDrivenInterceptor could change the stack order when a refresh is necessary; the old model is removed from wherever it was in the stack and the new model is simply pushed.
>>
>> Is it worth mentioning?
>>
>> Thanks,
>> Dave
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
Posted by Musachy Barroso <mu...@gmail.com>.
more details in the docs = less questions in the mailing list. Or not,
but it helps ;)
musachy
On Wed, Jul 16, 2008 at 2:24 PM, Dave Newton <ne...@yahoo.com> wrote:
> I'm not sure if this is a potential issue or not, so wanted quick feedback before deciding if a minor documentation change is warranted.
>
> It appears as though ModelDrivenInterceptor could change the stack order when a refresh is necessary; the old model is removed from wherever it was in the stack and the new model is simply pushed.
>
> Is it worth mentioning?
>
> Thanks,
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org