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
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
