Jacob Hookom wrote:
Hello All :-)
I currently have the new EL-API integrated into the jasper runtime and
it's used under the covers of the deprecated jsp.el.* classes. Ex,
ExpressionEvaluatorImpl within Jasper instead makes calls to a new
ExpressionFactoryImpl from the EL-API.
Yet to do:
1) Incorporate the new EL-API into the jasper-compiler
2) Incorporate the taglib definitions for deferred syntax #{..}
Ok.
I'd also like to bring up a possible performance optimization for EL.
Right now, all EL evaluations produced by the jasper-compiler are
referenced by the String expression-- causing a re-parse on every
invocation within commons-el. The optimization would be to have the
compiler actually retain reference to the parsed Node tree from
org.apache.el. This would basically marry the EL implementation to the
compiler-- so I guess it's somewhat of a trade-off.
I know the old EL implementation included some kind of cache too. I
never did any performance study of the EL, though.
In looking at the current EL compilation within Jasper, I'd like to rip
a lot of it out. Basically two code bases of the EL spec are being
maintained for parsing (one within the jasper compiler, and one from the
el-implementation). As a carry-over from my last suggestion, do you
think it would be practical to just use the org.apache.el for expression
validation without maintaining a separate set of parsing logic within
jasper itself?
Sure, if it's possible to have only one EL implementation, it would be
great.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
