Re: [OS-webwork] Re: OGNL

Maurice Parker Tue, 05 Nov 2002 11:28:38 -0800

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

Re: [OS-webwork] Re: OGNL

Reply via email to