Hi all, thanks for the answers..
>>Is there a particular expression language you are interested in? No. To be honest, I don´t care what implementation it is... The current implementation performs really well for me. But sometimes I need to use reflection inside my own code. This is why I´m thinking about the ognl service.. Click already expose some services -> ClickUtils.getLogService() regards, On Tue, Nov 18, 2008 at 3:38 AM, Bob Schellink <[EMAIL PROTECTED]> wrote: > Hi Ricardo, > > A related issue is this one: http://www.avoka.com/jira/browse/CLK-306 > > I agree with you that if we go through the effort of introducing a > different expression language it should > be through a service, but Click should only ship with one implementation. > > Is there a particular expression language you are interested in? > > kind regards > > bob > > > Malcolm Edgar wrote: > >> 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. >>> >>> >>> >>> >> >> >> > > -- Ricardo Lecheta
