The Proliferation of Expression Languages.
Looks like there's a proliferation of Expression Languages (i.e. EL) in the Java world. An EL (according to me) is a mini language that helps express navigation through an object graph. So this doesn't include regex's w/c navigate strings and xpath w/c navigate xml. For starters there's JSTL and there's Jexl which adds a few more conveniences like support for invocation of methods. Why this isn't included in JSTL is beyond me!. At least Webwork EL supports method invocation, furthermore it's got an eval() like capability which can prove to be pretty useful.
There's Joda which leverages Jaxen and JXPath, both are languages based on XPath. XPath based EL's are more expressive and powerful than the JSTL variants. With XPath based languages you don't have to specify the exact path to an object, you can choose to ignore objects in the path. There's also OGNL supports a variant of lamda functions, although I don't think it's as powerfull as the XPath based ones.
Just to get you a feel of why EL's are useful, here's some motivation from the JXPath intro.
Consider this example: Address address = (Address)JXPathContext.newContext(vendor). getValue("locations[address/zipCode='90210']/address");
This XPath expression is equvalent to the following Java code: Address address = null; Collection locations = vendor.getLocations(); Iterator it = locations.iterator(); while (it.hasNext()){ Location location = (Location)it.next(); String zipCode = location.getAddress().getZipCode(); if (zipCode.equals("90210")){ address = location.getAddress(); break; } }
Stuff like this makes C# foreach construct look downright primitive!
[::Manageability::]
Agreed. I love expression languages for Java! Plus I think Jexl rocks.
Quite a while ago I mused about using XPath syntax to query Java objects. I love XPath, I think its a great language (I've spent enough time hacking it on dom4j and Jaxen) and at the time I really thought it'd be great to use it for Java objects too.
Since then, through working on the JSTL expert group helping define the EL in JSP and JSTL and working with Jexl and Jelly, I've come to a different conclusion.
XPath is a bit too complex and (unsuprisingly) XML centric with some unnecessary XML baggage. We should have a standard EL for Java that is Java centric usable by page authors and Java developers alike.
For me the big thing missing from XPath for Java is the use of method invocation. In an EL I want to be able to do things like
customer.orders[12].calculateTax('uk')
This is the feature that makes working with Jexl and Velocity so cool. Indeed anyone who's done any Velocity will realise this single feature is essential.
From a standards perspective, the EL in JSP and JSTL came from a desire to make it easy for page authors (who are not necessarily Java developers) to access information inside beans without having to write Java code. So its focussed on making it easy to access properties, provided syntax sugar for hiding the differences between indexed properties, arrays, Collections, Maps etc.
So the EL in JSP and JSTL is cool - though I'd like it to go much further so that its also really cool for use by Java developers to provide method invocation and more.
So I far prefer Jexl which is a superset of the JSP and JSTL ELs, with full Velocity style method invocation. (Its hardly suprising, with Mr Velocity, Geir Magnusson Jr being the creator of Jexl).
Now it could be really cool to add the one missing feature of XPath, that of predicate expressions, to Jexl. So you could do things like
customer.orders[amount > 12 and isDeliverableTo('uk')].calculateTax('uk')
Then we'd have all bases covered. Incidentally the above are 'naked' Jexl expressions. when using these sorts of expressions inside Jelly or JSP you wrap them in ${}, such as ${customer.name}
Also note that Jexl also supports DynaBeans as well as regular beans and mapped properties which is a term used on the commons-beanutils project to be a property indexed by a String key such as... public interface Foo {
// a sample mapped property Object get(String property);
}
Which could then be accessed via
${foo.name}
which would call foo.get( "name" );
7:15:57 AM 
|
