I think this will have to wait until after 1.3. The alpha release will happen very soon and hopefully after a couple of quick bug fix rounds we will be able to release 1.3. After that I'm sure that it will be a high priority item.

Vedovato Paolo wrote:

Could this taglib performance improvement be examined a little deeper for
1.3? This would a very big gain for webwork especially when having a look at
the JSTL comparison mentioned by Maurice.
Cheers
-Paolo


-----Original Message-----
From: Maurice Parker [mailto:maurice.parker@;pmic.com]
Sent: Tuesday, November 05, 2002 8:25 PM
To: [EMAIL PROTECTED]
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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to