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 #{..}
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.
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?
I guess coming from the Facelets project, I just delegated pre-parsing
to the javax.el.ExpressionFactory instead of re-implementing the EL-spec
within the compiler.
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
