jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stu Robertson <srobert...@nvisia.com>
Subject Re: [RDC] setting rdc ids at runtime
Date Fri, 05 Aug 2005 13:44:15 GMT
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.



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 <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>
>     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 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:        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

To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

View raw message