On Fri, 15 Mar 2002, John Baker wrote:
> > The 'rt' versions of each tag library support rtexprvalues instead of the
> > expression language. We included them primarily as a way of facilitating
> > integration of JSTL into older applications and methodologies. The 'rt'
> > versions won't be necessary once JSP itself supports the expression
> > language.
> >
> > Section 1.3 of the JSTL Public Draft describes the situation more
> > completely.
>
> I see. That does make a lot more sense. But I don't understand this:
>
> > The 'rt' versions won't be necessary once JSP itself supports the
> > expression language.
JSP 1.3 has plans to support an expression language through the entire JSP
page (not just for custom-tag attributes). Given this, there eventually
won't be a need for two different versions of each JSTL tag library. In
the future, one could write:
<c:forEach items="${session.data}">
and
<c:forEach items='<%= session.getAttribute("data") %>'>
against the same tag library (TLD and tag handlers).
Technically, this would be possible now; that is, the same tag handler
could support both. But since, under JSP 1.2, a tag handler can't figure
out whether it retrieved a String using an rtexprvalue or whether or not
that String was passed literally, we had to account for the situation
where an rtexprvalue would return something that looked like an
expression; this would cause an undesirable (and perhaps insecure) double
evaluation. For instance, something as simple as
You said your name was <c:out value='<%= request.getParameter("foo")'/>
would not necessarily be secure. Why? Because getParameter("foo") is
under the user's control, meaning that it could be set to something like
"${session.secureData}", at which point the tag would evaluate this result
as an expression, causing the tag to expose secure data unintentionally.
To address this, we first thought to use two different attributes for each
tag (e.g., "items" and "items_"), but this got to be cumbersome very
quickly, and the syntax was ugly. Other alternatives included an
attribute-based "switch" for each tag (e.g., expressions="true"), but this
wasn't convenient and would need to operate on the level of each
individual attribute in order to be granular enough. Parent tags that
adjusted subtags' evaluative algorithm could have worked, but were
somewhat dangerous and difficult to explain. Thus, we opted for two
parallel tag libraries. It lets you make the decision once and then
forget about it again until you need to re-evaluate.
In JSP 1.3, the extra tag library can likely go away because evaluation of
rtexprvalues and 'elexprvalues' will occur at the same level of
abstraction; expression-language evaluation won't be subordinate to
rtexprvalue execution.
So, are you sorry you asked yet? :-)
--
Shawn Bayern
Author, "JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
