It's not a question of uniqueness though. Yes, ids must be unique.
In no way does setting an id's value from an expression imply that it
will not be unique for a particular page. In our case we have one
RDC per page. The same uniqueness constraint can be maintained with
page templates having multiple RDCs. It sounds to me like the
"uniqueness" reply is a rationalization for accepting a significant
application-space limitation of the RDC library due to its use of tag
files throughout.
Foundational libraries such as the RDC should, in my opinion, only
impose restrictions on its users which are necessary for providing
it's functionality, or to maintain some convention (best practices,
for instance). In this case, the restriction is there only because
an optional implementation strategy for RDC core tags is being used.
Could you explain your workaround a bit more? I'm definitely
interested. Are you suggesting creating my own tagx files, which
accept expressions and then call RDC components? If so, I don't see
how this solves the problem, as now these tagx files will have the
same problem passing the ids to RDCs.
Thanks,
Stu
On Aug 5, 2005, at 6:39 AM, T. V. Raman wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
