I think I need to read more code to follow this thread...I promise.
2008/7/17 Ted Husted <[EMAIL PROTECTED]>:
> 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, tha
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
--- On Thu, 7/17/08, Ted Husted <[EMAIL PROTECTED]> 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 RefreshModelB
+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").
--- On Thu, 7/17/08, Ted Husted <[EMAIL PROTECTED]> 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
-
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
>>
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 objec
gt; Subject: Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
> To: "Struts Developers List" , [EMAIL PROTECTED]
> Date: Thursday, July 17, 2008, 9:08 AM
> The map would be just an auxiliary data structure to
> maintain this
> propertyName -> ownerObje
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 followin
--- 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
> where the key is the property name, and the value is
>
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 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
--- 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
-
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
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
--- 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
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 <[EMAIL PROTECTED]>:
> more details in the docs = less questions in the mailing list. Or not,
> but it helps ;)
>
> m
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 <[EMAIL PROTECTED]> 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
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
sta
18 matches
Mail list logo
