Pluggable Expression Language is the first thing that came to my mind when I saw discussion about OGNL on WebWork's mailing list. I think you should file this idea in Jira.
Cheers, ___________________________ François Beauregard, b.ing. Vice-président Recherche et développement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:opensymphony-webwork-admin@;lists.sourceforge.net]On Behalf Of Patrick Lightbody Sent: November 5, 2002 2:33 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: OGNL On a related note, Ognl does have an expression language itself: Ognl.getValue("foo.bar", bean, ...) will evaluate getFoo().getBar(). Could we take advantage of this? Ognl actually can accept a pre-compiled expression (a Node object), so we could write a parser that that took "foo/bar" and generates a Node tree that Ognl could use. This would essentially equate to ditching our expression language in terms of implementation and using Ognl. All we'd do (for compatability) is write a WebWork EL->Ognl expression parser. Just a wild idea I'm throwing out there... :) For more info on Ognl's expression language, check out www.ognl.org. It has a HUGE ammount of power in there. -Pat ----- Original Message ----- From: "Maurice Parker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 11:24 AM Subject: Re: [OS-webwork] Re: OGNL > Bill, > > I've never profiled the EL and taglibs. Do you have anymore details > about what in the findValue() method is eating cycles? I think you > mentioned PropertyEditor in the past. > > BTW, there is probably lots of room for improvement in our Taglib > implementation. I once coded a JSTL version of monthlist.jsp and it ran > in about a third of the time. I would expect us to be somewhat slower > because of added functionality and the upward stack search, but not that > slower. > > -Maurice > > > Bill Lynch wrote: > > >Pat, > > > >What would the performance difference be between the current implementation of > >ValueStack.findValue() vs the OGNL-implemented one? In all my profiling, > >ValueStack.findValue() always pops to the top as the method that takes the > >longest. > > > >Regards, > >--Bill > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:opensymphony-webwork-admin@;lists.sourceforge.net]On Behalf Of > >>Patrick Lightbody > >>Sent: Tuesday, November 05, 2002 1:41 PM > >>To: [EMAIL PROTECTED] > >>Subject: Re: [OS-webwork] Re: OGNL > >> > >> > >>Yup yup... > >> > >>One note (just to keep everyone aware and maybe they can think of better > >>ideas): > >> > >>ValueStack.findValue() does not use BeanUtil to find values (it does it's > >>own reflection). One thing that would be nice would be to change findValue() > >>to use Ognl in the future for getting properties from beans. Then, in order > >>to make it possible to type-convert back to original form (I'll keep using > >>the MM/dd/yyyy example), findValue must be able to take an a Class to find > >>the value as: > >> > >>findValue(String expr) { > >> return findValue(expr, Object.class); > >>} > >> > >>findValue(String expr, Class clazz) { > >>.... > >>// I need a property from a bean > >>Ognl.getValue(bean, context, expr, clazz); > >>.... > >>} > >> > >>Overall, I think the ValueStack is a very useful feature, but it could be > >>"more informed" so to speak. For example, in Ognl, the context will hold the > >>type converter that is to be used for the get/setValue operation. If in > >>XWork (again, all hypothetical) you can configure global/bean/property-level > >>type-converters, then when the above Ognl.getValue() call is made, the > >>context must have the right type-converter set. This is somewhat tough (if > >>not impossible) given the current ValueStack design. > >> > >>The ValueStack is a dumb stack, so to speak. It's very, very UNinformed. It > >>does the job, but it doesn't know the context in which it's doing it in. And > >>the value stack GETS values from beans (think Ognl.getValue). This is very > >>different from the dispatchers (GenericDispatcher), where the code is very, > >>very INformed. It knows exactly the context it's running in and therefore > >>can SET bean values correctly (think Ognl.setValue). So this mix-match > >>between the dispatch and the ValueStack is bad and should be fixed in > >>version 2.0. > >> > >>-Pat > >> > >> > >>----- Original Message ----- > >>From: "Maurice Parker" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Tuesday, November 05, 2002 10:30 AM > >>Subject: Re: [OS-webwork] Re: OGNL > >> > >> > >> > >> > >>>Chris Miller wrote: > >>> > >>> > >>> > >>>>Maurice's point about stability before functionality is of course > >>>> > >>>> > >>extremely > >> > >> > >>>>valid too, but if Pat is keen to code this on a branch in the meantime I > >>>>can't see any reason to discourage him. > >>>> > >>>> > >>>> > >>>> > >>>Let me let everyone know a little bit more about where I'm coming from > >>>on this. Of the new code in CVS that has caused so many problems, > >>>Patrick and myself are the two of the main contributers. Neither of us > >>>has done good job on quality with that code and Rickard rightfully > >>>chewed our asses for it. > >>> > >>>I feel that if you add code to the CVS repository you have the > >>>responsibility of leaving it at least as good and hopefully better than > >>>before. To make things right I am working on the new testsuite, trying > >>>to find bugs, and working my way through the bugs in Jira. > >>> > >>>I think Patrick feels much the same way that I do, so the OGNL stuff can > >>>wait a little longer. > >>> > >>>-Maurice > >>> > >>> > >>> > >>> > >>>>"Hani Suleiman" <[EMAIL PROTECTED]> wrote in message > >>>>news:1036517903.3dc8020f7b62a@;mail.formicary.net... > >>>> > >>>> > >>>> > >>>> > >>>>>Well, the ognl stuff seems very promising, how about having it > >>>>> > >>>>> > >>implemented > >> > >> > >>>>> > >>>>> > >>>>on a > >>>> > >>>> > >>>> > >>>> > >>>>>branch (say, OGNL_1 or something), with a view to integrating it once > >>>>> > >>>>> > >>>>> > >>>>> > >>>>others > >>>> > >>>> > >>>> > >>>> > >>>>>have had a look and feel it's worthwhile? > >>>>> > >>>>>Again, I stress that the goal for adding it (from my perspective at > >>>>> > >>>>> > >>least) > >> > >> > >>>>> > >>>>> > >>>>is > >>>> > >>>> > >>>> > >>>> > >>>>>performance. There should be NO configuration changes, and absolutely NO > >>>>>external changes. The only different (hopefully) will be superior > >>>>> > >>>>> > >>>>> > >>>>> > >>>>performance on > >>>> > >>>> > >>>> > >>>> > >>>>>the branch version. If it ends up being > >>>>> > >>>>> > >>ugly/unusable/slow/unfashionable, > >> > >> > >>>>> > >>>>> > >>>>the > >>>> > >>>> > >>>> > >>>> > >>>>>branch can merrily die off, if it's useful/pretty/a positive step, it > >>>>> > >>>>> > >>can > >> > >> > >>>>> > >>>>> > >>>>land > >>>> > >>>> > >>>> > >>>> > >>>>>on HEAD. Any objections? > >>>>> > >>>>> > >>>>> > >>>>>------------------------------------------------------- > >>>>>This sf.net email is sponsored by: See the NEW Palm > >>>>>Tungsten T handheld. Power & Color in a compact size! > >>>>>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>>------------------------------------------------------- > >>>>This sf.net email is sponsored by: See the NEW Palm > >>>>Tungsten T handheld. Power & Color in a compact size! > >>>>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > >>>>_______________________________________________ > >>>>Opensymphony-webwork mailing list > >>>>[EMAIL PROTECTED] > >>>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>>------------------------------------------------------- > >>>This sf.net email is sponsored by: See the NEW Palm > >>>Tungsten T handheld. Power & Color in a compact size! > >>>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > >>>_______________________________________________ > >>>Opensymphony-webwork mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>> > >>> > >> > >>------------------------------------------------------- > >>This sf.net email is sponsored by: See the NEW Palm > >>Tungsten T handheld. Power & Color in a compact size! > >>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > >>_______________________________________________ > >>Opensymphony-webwork mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > >> > >> > > > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by: See the NEW Palm > >Tungsten T handheld. Power & Color in a compact size! > >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > >_______________________________________________ > >Opensymphony-webwork mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork