Kiss My App

Saturday, October 28, 2006

Extending EL Syntax

I've dabbled a bit with EL in the past for both Glassfish and Tomcat. Performance wise, no one's said the 'larger' feature set has caused performance problems (ELResolvers, ELContext, VariableMapper, etc). What I have seen, is people complaining about performance with OGNL. So what I want to see happen is for an EL implementation to fill in the necessary pieces to migrate OGNL users over to the EL API.

First, we of course need to support method invocation. This is pretty straight forward and will be considered a Value clause, just as a.b == a.getB().

Secondly, we would want to support projections/transformations/predicates within the language. I'm thinking that introducing '@' into the syntax would be the most readable solution as opposed to using dot notation with reserved literals. In addition, you don't always require a literal declaration of the projection and we could reduce expressions to something like:

#{company.employees@name} a collection of Employee names
#{company.employees@hashCode()} a collection of Employee hashCodes

If you wanted to specify the projection, then these two are equivalent:


Also, we could have some reserved projections for selection/sorting/etc:

sort by name

employee with the most salary

only employees with a 6 figure salary
#{company.employees@only{x|x.salary > 100000}}

highest salary only

the first employee found with the name of 'Bob'
#{company.employees@first{x| == 'Bob'}}

Also, the EL-API has MethodExpressions where the expression represents a pointer to a method: #{employee.addAddress} and you could invoke the MethodExpression with an Address object. If we used this in combination with projections, we could do some neat stuff like:

Invoke on each ActionListener


Post a Comment

<< Home