This is the third installment of a series. Parts II is here:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/2007/07/09#ee6part2
The new Unified EL API used by JSF and JSP is a really useful addition to the Java platform. Unfortunately, while a lot of effort was put into designing the Java-level APIs for working with Unified EL, the expression language itself hasn't changed much since the earliest days of JSP. It is now well past time for some new features. A more powerful EL lets us keep presentation logic in our page, and avoids polluting the business model with extra methods.
Here's some suggestions I have, though I'm not at all attached to the suggested syntaxes.
Method parameters
This is one of those what were they thinking?!
moments. Unified EL does not support method expressions with parameters. Really.
Suggested syntax:
customer.getOrder(ordernumber).product.name
Switch statement
In JSP or JSF pages it's very useful to be able to handle multiple cases in a single expression.
Suggested syntax:
switch (order.status) { case OPEN: 'Open' case CLOSED: 'Closed' else '' }
Dates and times
Currently, there is no way to compare dates and times in EL. The <, >, <= and >= operators should be extended to support java.util.Date. It may also be worth introducing a syntax for date/time literals.
Collection size operator
Amazingly, there is no simple way to determine the size of a collection in EL!
Suggested syntax:
size customer.orders
This operator should work for any Collection, Map, String or Iterable. Furthermore, the empty operator should be extended to support Map and Iterable.
Collection constructors
When defining pages, it is useful to be able to iterate over collection literals.
Suggested syntax for creating a java.util.List instance:
{'foo', 'bar', 'baz'}
Suggested syntax for creating a java.util.Map instance:
{'foo'->1, 'bar'->3}
Suggested syntax for creating a java.util.List instance with for a specified range of integers:
{1...100}
Collection iteration
This feature is a kind of poor-man's closure support. It should work for all instances of Iterable.
The following suggested syntax returns the list {2, 3, 4}:
{1, 2, 3} collect { x -> x+1 }
The following returns {2, 3}:
{1, 2, 3} select { x -> x>1 }
The following returns the object 2:
{1, 2, 3} detect { x -> x>1 }
The following returns the object 3:
{1, 2, 3} detect { max, x -> max>=x }
The following returns {3, 2, 1}:
{1, 2, 3} desc
The following sorts the customers by name:
customers asc { c -> customer.name }
An alternative approach might be to copy Python's list comprehensions:
[ x+1 for x in {1, 2, 3} where x>1 ]
which results in {3, 4}.
Conclusion
The point of this is not to turn Unified EL into a programming language. I actually prefer it to be relatively bare-boned compared to OGNL or MVEL. Rather, the point is to remove certainl pain-points where the only current solution is to fall back to writing presentation logic in Java code.
An alternative to improving the Unified EL would be to allow JSF/JSP expressions to be writting in JavaScript, Groovy, or some other scripting language. I'm openminding on that, it would certainly be possible to wrap the JavaScript interpreter behind a Unified EL ExpressionFactory. But I worry that it pushes people in the wrong direction of writing templates that contain procedural code. The last thing I want to see is JSF templates that look like .rhtml files ;-)
