jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject [standard] ECMA-Script EL comments and enhancements
Date Tue, 22 Jan 2002 18:22:07 GMT
Hi Shawn et al.,

having played a little more with ECMA-Script in JSTL, I'd like 
to give some feedback as well as a contribution.

Generally, I think that using JavaScript/ECMAScript as the 
global expression language in JSTL and even JSP.next would be 
a good decision. The target group of JSP authors are obviously 
web-page designers, and those people are usually (or at least 
should be) very familiar with JavaScript for client-side 
scripting. Even though the usual complexity of expressions in
JSTL-based pages is probably fairly low, using a different 
scripting language would force web-page designers to learn a 
new language. ECMA-Script is easy, popular and standardized
(which is also a good argument towards managers :P).

As written in the documentation, XPath is indeed the natural 
choice for the select-attribute of the XML-tags. But IMHO it is 
too complex and unfamiliar for using it as the global EL.

That said, I've spent some time today enhancing the ECMA-Script 
support in JSTL. Most importantly, I wanted to be able to use 
associative containers directly from JavaScript, which is quite 
natural as every JavaScript object is actually just a 
associative container from the user's point of view. So, given a 
Map with String-type keys, I wanted to be able to write:

  <c:expr value="$map.key" default="ouch"/>

or at least

  <c:expr value="$map['key']" default="ouch"/>

And especially, I wanted to be able to use that syntax to access 
request parameters:

  <c:if test="$params.action != null">
    <c:expr value="$params.action[0]" default="(nothing)"/>

And while at it, I've also added support for accessing List 
objects using the [] operator, just as a normal array.

This is implemented by making JavascriptExpressionEvaluator implement 
org.mozilla.javascript.WrapHandler, and registering itself as 
WrapHandler with the Rhino Context. In the wrap() method, we look if 
the object to wrap is an instance of either List or Map, and wrap it 
into Adapter classes (o.a.t.s.lang.javascript.adapter.NativeJavaList
and o.a.t.s.lang.javascript.adapter.NativeJavaMap, respectively). 
Otherwise, the default WrapHandler will do the wrapping.

The archive attached to this mail contains the patches and new files 
to implement the functionality described above, and extends the 
standard-examples webapp to demonstrate the features.

Would be happy about any comments on this stuff,
cmlenz at gmx.de

View raw message