jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T. V. Raman" <tvra...@us.ibm.com>
Subject Re: [RDC] setting rdc ids at runtime
Date Fri, 05 Aug 2005 11:39:59 GMT

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 <srobertson@nvisia.com> 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> 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> 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> In the JSP spec, section on Validity
    Stu> Constraints, the UniqueVariableName item states
    Stu> (sorta...it's somewhat confusingly worded):
    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> More helpful was Table JSP.8-4, which says of
    Stu> name-from-attribute:
    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> 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> 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> 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> 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> 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> 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> 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> Thoughts?
    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,
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:        tvraman@us.ibm.com
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: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

View raw message