Stu ---
I fully expected this:-)
The problem in a line is that JSP-2.0 tags use pass by name.
In the RDC implementation, we're using the id to instantiate the
page-scope variable that is used to pass the value back to the
caller from the tag implementation
We chose this direction specifically saying there are many other
reasons why xml:id will be unique --- at least in the XML file
once it's created;
when you tried to make id an expr, what you tried to do to JSP2.0
was to attempt call by name where the name itself was dynamic ...
Incidentally I believe many of your use cases can be addressed
without using ids an expression; for instance, I suggest
constructing a page/task-level template mechanism at the same
level as what we have for RDC component templates.
>>>>> "Stu" == Stu Robertson <[EMAIL PROTECTED]> writes:
Stu> I took a swing at implementing this today. I fully
Stu> expected the change to be trivial. It turns out to be
Stu> (I think) impossible, though I have a hack suitable for
Stu> our purposes, but which doesn't belong in the
Stu> distribution. I'll go into a bit of detail below
Stu> because it will be useful to others who try this,
Stu> especially since it turned up what I think is a spec
Stu> violation in WAS 6 (PMR submitted this afternoon).
Stu>
Stu> Logically the change simply involves allowing the id
Stu> attribute to be passed to a RDC as an expression. Just
Stu> like every other attribute in the RDCs. Setting the
Stu> rtexpression attribute in the tag file to true seemed to
Stu> be all it would take. Doing that produced the expected
Stu> results within the RDC itself, and it worked fine.
Stu>
Stu> The problem was that the page variable passing the RDC's
Stu> result was never set in the calling page. It turns out
Stu> that the variable synchronization mechanism newly
Stu> defined in the JSP 2.0 spec for tag files simply doesn't
Stu> allow it.
Stu>
Stu> In the JSP spec, section 1.3.10.2 on Validity
Stu> Constraints, the UniqueVariableName item states
Stu> (sorta...it's somewhat confusingly worded):
Stu>
Stu> "A translation error must occur if there is a variable
Stu> di- rective with a name-from-attribute attribute whose
Stu> value is not equal to the name attribute of anattribute
Stu> directive in the same translation unit that is also of
Stu> typejava.lang.String, that is required and that is not
Stu> an rtexprvalue."
Stu>
Stu> More helpful was Table JSP.8-4, which says of
Stu> name-from-attribute:
Stu>
Stu> "The specified name is the name of an
Stu> attributewhose(translation-time)valueatofthestartofthe
Stu> tag invocation will give the name of the variable. "
Stu>
Stu> In short, the mechanism provided for 2.0 tag files for
Stu> passing results back to the calling page via the
Stu> pageContext requires that the original value passed in
Stu> cannot be from an expression.
Stu>
Stu> WAS 6 happily translated, compiled and ran the modified
Stu> tag though, making it very tricky to hunt down the
Stu> problem (for me at least :-).
Stu>
Stu> Anyway, yuck. This is a very surprising limitation of
Stu> tag files. Java tag handlers have no such limitation,
Stu> and share the pageContext of the calling page. Tag
Stu> files receive a "wrapped" page context, and have no
Stu> direct access whatsoever to the calling context - you
Stu> have to use the provided mechanism. I understand why
Stu> they did it, and that it's an inevitable consequence of
Stu> the new ability to compose tags from other tags without
Stu> having them stomp on each other's variable space.
Stu>
Stu> Now that it's clear that RDCs _had_ to disallow the id
Stu> attribute from being an expression, I'd like to find out
Stu> if there are any reasons why it _should_ not, current
Stu> implementation details aside.
Stu>
Stu> I can only think of drawbacks. It takes away from users
Stu> of this library the ability to create templates in
Stu> application-space. In our case, it would mean many JSPs
Stu> differing only by the fact that each would have a
Stu> different static value for the id attribute. We will be
Stu> using a modified set of tags to allow templating (we
Stu> pass the value via the request, the only option I could
Stu> think of - which is also yuck), but this bypasses a
Stu> substantial portion of the benefit of using a third
Stu> party library.
Stu>
Stu> What's more, aside from the fact that you can't support
Stu> this using tag files, this limitation is not in any way
Stu> required by RDCs. In JSP 2.0, a java TagHandler (of any
Stu> type) is, I believe, unaware that an attribute's value
Stu> was even passed in as an expression since it's evaluated
Stu> by the container. At runtime, the RDC just gets the id
Stu> value, static or dynamic, and does its thing.
Stu>
Stu> That's my take on this at least. I'm new to JSP 2.0, so
Stu> it's not unlikely I just don't understand how to use it
Stu> fully.
Stu>
Stu> Thoughts?
Stu>
Stu> Stu
Stu>
Stu> p.s. - I'm probably not doing a very good job of hiding
Stu> my thought that this is yet another reason we'd get
Stu> substantial value out of
Stu> reimplementing RDCs as normal non-tag-file TagHandlers :-)
--
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman: PhD (Cornell University)
IBM Research: Human Language Technologies
Architect: RDC --- Conversational And Multimodal WWW Standards
Phone: 1 (408) 927 2608 T-Line 457-2608
Fax: 1 (408) 927 3012 Cell: 1 650 799 5724
Email: [EMAIL PROTECTED]
WWW: http://almaden.ibm.com/u/tvraman (google:tv raman
AIM: emacspeak
GPG: http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail: IBM Almaden Research Center,
650 Harry Road
San Jose 95120
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
