I took a swing at implementing this today. I fully expected the
change to be trivial. It turns out to be (I think) impossible,
though I have a hack suitable for our purposes, but which doesn't
belong in the distribution. I'll go into a bit of detail below
because it will be useful to others who try this, especially since it
turned up what I think is a spec violation in WAS 6 (PMR submitted
this afternoon).
Logically the change simply involves allowing the id attribute to be
passed to a RDC as an expression. Just like every other attribute in
the RDCs. Setting the rtexpression attribute in the tag file to true
seemed to be all it would take. Doing that produced the expected
results within the RDC itself, and it worked fine.
The problem was that the page variable passing the RDC's result was
never set in the calling page. It turns out that the variable
synchronization mechanism newly defined in the JSP 2.0 spec for tag
files simply doesn't allow it.
In the JSP spec, section 1.3.10.2 on Validity Constraints, the
UniqueVariableName item states (sorta...it's somewhat confusingly
worded):
"A translation error must occur if there is a variable di-
rective with a name-from-attribute attribute whose value is not equal
to the
name attribute of anattribute directive in the same translation unit
that is also
of typejava.lang.String, that is required and that is not an
rtexprvalue."
More helpful was Table JSP.8-4, which says of name-from-attribute:
"The specified name is the name of an
attributewhose(translation-time)valueatofthestartofthe
tag invocation will give the name of the variable. "
In short, the mechanism provided for 2.0 tag files for passing
results back to the calling page via the pageContext requires that
the original value passed in cannot be from an expression.
WAS 6 happily translated, compiled and ran the modified tag though,
making it very tricky to hunt down the problem (for me at least :-).
Anyway, yuck. This is a very surprising limitation of tag files.
Java tag handlers have no such limitation, and share the pageContext
of the calling page. Tag files receive a "wrapped" page context, and
have no direct access whatsoever to the calling context - you have to
use the provided mechanism. I understand why they did it, and that
it's an inevitable consequence of the new ability to compose tags
from other tags without having them stomp on each other's variable
space.
Now that it's clear that RDCs _had_ to disallow the id attribute from
being an expression, I'd like to find out if there are any reasons
why it _should_ not, current implementation details aside.
I can only think of drawbacks. It takes away from users of this
library the ability to create templates in application-space. In our
case, it would mean many JSPs differing only by the fact that each
would have a different static value for the id attribute. We will be
using a modified set of tags to allow templating (we pass the value
via the request, the only option I could think of - which is also
yuck), but this bypasses a substantial portion of the benefit of
using a third party library.
What's more, aside from the fact that you can't support this using
tag files, this limitation is not in any way required by RDCs. In
JSP 2.0, a java TagHandler (of any type) is, I believe, unaware that
an attribute's value was even passed in as an expression since it's
evaluated by the container. At runtime, the RDC just gets the id
value, static or dynamic, and does its thing.
That's my take on this at least. I'm new to JSP 2.0, so it's not
unlikely I just don't understand how to use it fully.
Thoughts?
Stu
p.s. - I'm probably not doing a very good job of hiding my thought
that this is yet another reason we'd get substantial value out of
reimplementing RDCs as normal non-tag-file TagHandlers :-)
