Should we continue to use OGNL for parameter binding? This creates so
many possible security holes, in exchange for pretty much nothing,
when parameter names should be simple (indexing + the old A.B.C
notation).
Are there any uses cases where the full OGNL power is needed, for
parameter binding?
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
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
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 ;)
--- 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.
I wrote my own for the JCatapult MVC and it does most of the parameter
setting stuff that OGNL does and a few other things like handling
generics correctly and completely. It also has a pretty solid type
conversion API. Took about 3 days to write, test and complete. Feel
free to grab the
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
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 MapString,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
