tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: JSTL (standard taglib) Early Access 2
Date Thu, 22 Nov 2001 21:25:21 GMT
Shawn Bayern wrote:
> [...]

Thanks for the new release. It's nice to be able to play around and test
the new tags.

> The EA2 release contains proposed standard tags for internationalization,
> data retrieval (via URLs), formatting, and XML manipulation (using XPath
> and XSLT).  It incorporates several new candidate scripting languages,
> notably including ECMAScript (most familiar in its incarnation as
> JavaScript).  [...]

I found a problem with the JspSource.jsp page, now when ECMAScript is
the default EL. This page uses EL expressions to show the value of the
"filename" parameter in the head of the page as well as in the main
header in the body, e.g:

  <title>JSTL: Source code for <c:expr value="$param:filename"/></title>

The problem is that the ECMAScript EL doesn't seem to understand the
"param:" scope prefix, so this throws an exception. It's clearly a
bug that needs to be fixed in the standards package.

But this brings up another issue that may be better discussed within
JSR-052, but I describe it here in case someone else has comments.

I looked through the ECMAScript EL description and couldn't find any 
support for access to objects in non-standard scopes like "param", 
"header", "cookie" etc. Am I missing something, or is this simply not 
part of the the ECMAScript EL? If so, it makes it a bit hard to use 
ECMAScript as an EL, since a lot of expressions need access to at least 
the "param" scope, as well as what's called the "parameterValues" scope 
in SPEL.

It would be great if support for at least the same scopes as in SPEL
could be added to ECMAScript EL, ideally with similar syntax so I can 
explicitly specify a scope and not just pick the first object that matches 
the name in any scope.

I'm also a bit concerned about examples like "$new String('Hello there')"
in FunctionCall.jsp. Do we really want the complete ECMAScript power, 
including the ability to create new objects, in an EL? I'm afraid this
will cause the same kind of problems as using Java as a scripting language, 
with many unforeseen issues. Don't get me wrong; I like the idea of using 
an existing language instead of inventing a new one, and most page authors 
are familiar with ECMAScript from client-side scripts. But I would prefer 
a subset of ECMAScript as the EL instead of the full functionality. Can 
Rhino be configured to only expose a subset?

Hans Bergsten
Gefion Software
Author of JavaServer Pages (O'Reilly),

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message