On this issue we did a bunch of testing around performance. Click uses Reflection with cached method caching for rendering/read operations, and this is very fast. There was not appreciable difference between Click's use of reflection and MVEL. You see a lot of reflection used in Table row data rendering.
Where Click uses OGNL is for writing/set operations. These are much less infrequent than read operations, and are used in Form setting and autobinding operations. My take on this is that we should probably use either OGNL or MVEL, but not both. In think swapping OGNL for MVEL could be on the roadmap for 1.6, but we really need a compelling reason to do this. Otherwise we will get the opportunity to find a new bunch of bugs :) regards Malcolm Edgar On Tue, Nov 18, 2008 at 1:33 PM, florin.g <[EMAIL PROTECTED]> wrote: > > If Click does not expose the ognl features to the framework user yet simply > uses it internally I would not see how this it benefits the user. I > appreciate the ability to swap the templating module (velocity, freemarker, > jsp) as using one over the other could be a religious thing. > > Unless mvel is faster? There was a discussion here before regarding this > issue. > > > > > > Ricardo Lecheta-2 wrote: >> >> Hi all, >> >> I was thinking about test some other reflection libraries, but the code is >> too tied to Ognl, or just normal reflection... >> >> So I remember that know Click has been refactored to use Services... >> >> What about create a Service to encapsulate all the reflection stuff ? >> >> So it would be easier to change from some OgnlService to other >> implementation. >> >> I´m not sure if this would be easier to do but... what do you all think >> about this? >> >> regards >> >> -- >> Ricardo >> >> > > -- > View this message in context: > http://n2.nabble.com/OgnlService--tp1511200p1512471.html > Sent from the click-development mailing list archive at Nabble.com. > >
