Would it work to first 'try' to assume it's an ognl expression, or would that just puke since no method exists? Worse yet, what if the method *does* exist but has nothing to do with the desired page? That's a subtle bug that would throw some people against the wall for a bit.
In the event the method doesn't exist and the attempt to get the value of the assumed ognl binding fails with an exception, you'd need to catch that exception and try the literal. Then you're using exceptions for control flow. I think it would be fine to set the default binding prefix to literal for this in 4.0.2, add the binding functionality and leave it at that. That would be transparently backward compatible AND let me use an ognl prefix to provide the name. Only in the next release where backwards incompatibility is already planned should the default go to ognl. That's my 2 cents, but if you're willing to fix it I'm willing to take whatever you'll give. It's unusable to me now, so anything is an improvement. Thanks again, -Mike On 4/13/06, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > Well. It's a backwards-incompatible change, that's for sure - but it is > one that in my humble opinion needs to be made. (We seem to agree about > that.) > > Now, if I were to fix this I'd go ahead and allow the object reference > to have a prefix for this particular service. I would add binding > functionality and default the prefix to OGNL. > > BUT in case the OGNL expression doesn't yield a valid result I'd assume > it's a literal string. If that doesn't yield a valid result either, I'd > assume it's an invalid OGNL expression. > > The whole deal is of course simplified if you actually specify a binding > prefix. : ) > > Does this make sense? Would it be an acceptable way to solve the problem? > > -Filip > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
