On 8/15/07 10:50 AM, in article [EMAIL PROTECTED], "Andrus Adamchik" <[EMAIL PROTECTED]> wrote:
> > Thinking about it some more .... > > This is not the end of the world for our application. We can either skip the > upgrade or indeed force an interface on the objects involved, or avoid > multi-step property traversal by moving it to Java class. > > But at a higher level it seems like the expression compilation algorithm is > sacrificing correctness for performance. An implicit requirement on the @For > to have homogeneous objects in the loop is confusing and non-obvious. A > failover strategy hidden from the users would be great. How hard it would be > to say decorate an expression compiled within a For loop in a try/catch that > would switch to a generic algorithm on the first ClassCastException? This is an interesting idea that I think would work well. We ran into "problems" ourselves. OGNL would dump out a ton of output to the console, but then fallback to an expression that would work. For example, our Border component had a lot of "ognl:page.something", where getSomething() is not defined in the IPage interface. Despite complaining, everything worked. In order to get rid of the logging, I had to add a class file for the Border, add a new getAppPage() that did little more than cast the getPage() call to an app-specific base page, and then update all my OGNL expressions to use that. It wasn't the end of the world, but a lot of additional overhead to prevent logging of failures if the thing is going to work anyway . . . -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
