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

Reply via email to