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
-
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 <[EMAIL PROTECTED]> wrote:
> Pushed properties don't have names, just positions, AFAIK.
>
> If you look at the code for ModelDrivenInterceptor my original reply might
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
I think it would be the same, we would just need to add a method to
ValueStack, to clear the context.
musachy
On Thu, Jul 17, 2008 at 5:32 PM, Chris Pratt <[EMAIL PROTECTED]> wrote:
> Will it be pluggable between the new-and-improved ValueStack and the
> OGNL ValueStack so that we can make the tr
Will it be pluggable between the new-and-improved ValueStack and the
OGNL ValueStack so that we can make the transition as painless as
possible?
(*Chris*)
On Thu, Jul 17, 2008 at 2:28 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Yeah I am set to fix those security holes ;). Doing the change
Yeah I am set to fix those security holes ;). Doing the change below,
all tests pass, with the exception of some tests in
ParameterInterceptorTest, that need to inject dependencies, and others
that check for the order of the values added to the stack (new context
is created here, so they fail)
+
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-
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
> I haven't seen any obstacles to a change like that. It would be nice if we
> could reuse a param binding implementation with type-conversion from
> somewhere else rather reinvent another.
Yes, definitely. Any suggestions? What is the status of Commons beanutils?
musachy
--
"Hey you! Would you
--- 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
>
13 matches
Mail list logo
