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 04:10:10 GMT
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 on Validity Constraints, the  
UniqueVariableName item states (sorta...it's somewhat confusingly  

"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  

More helpful was Table JSP.8-4, which says of name-from-attribute:

"The specified name is the name of an
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  

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.



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 :-)
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message