You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Stu Robertson <sr...@nvisia.com> on 2005/08/04 05:19:07 UTC
[RDC] setting rdc ids at runtime
The id attribute of the RDCs does not allow the value to be set via
an expression, unlike all other attributes I've found.
We're implementing our applications using the simplest possible
pattern, where each JSP contains a single RDC. So the JSPs
themselves are identical for a given type of RDC. We have quite a
few selectOne tags in an average application. The bits that vary
between page, in our design, are populated by expressions, getting
their values from state stored in the session.
The only one causing trouble is the id. I've made the changes to the
RDCs we're using, and will be working though any kinks tomorrow. I
just wanted to find out if there was a particular reason why this
constraint was added, and so maybe anticipate issues with other
plumbing bits.
Thanks,
Stu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [RDC] setting rdc ids at runtime
Posted by Stu Robertson <sr...@nvisia.com>.
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 <sr...@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 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: 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
Re: [RDC] setting rdc ids at runtime
Posted by "T. V. Raman" <tv...@us.ibm.com>.
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 <sr...@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 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: 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
Re: [RDC] setting rdc ids at runtime
Posted by Stu Robertson <sr...@nvisia.com>.
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 1.3.10.2 on Validity Constraints, the
UniqueVariableName item states (sorta...it's somewhat confusingly
worded):
"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
rtexprvalue."
More helpful was Table JSP.8-4, which says of name-from-attribute:
"The specified name is the name of an
attributewhose(translation-time)valueatofthestartofthe
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
space.
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.
Thoughts?
Stu
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 :-)
Re: [RDC] setting rdc ids at runtime
Posted by Stu Robertson <sr...@nvisia.com>.
> B) The expression may evaluate to an empty string
I'm not sure how this is unique to making the id attribute able to be
an expression. This is certainly true of every other attribute, and
an broken id couldn't break a JSP more than an incorrect config or
options attribute (we still need to work on error messages when
options don't resolve to a valid location). As always, the library
gives a certain amount of rope. Allowing them to make this an
expression if their design requires it doesn't mean it's the RDC's
fault if they incorrectly implement it.
> C) Group DM strategies such as the RuleBasedDirectedDialog or
> SCXMLDialog
> probably become unusable
I really like the DM strategy support - though we're not going to be
using it most likely ourselves (so far at least).
But allowing an attribute to be an expression doesn't mean it must be
one, just that it can. If you're using an RDC group tag in the style
of the examples - probably the most common case - then you can
continue to have the id be static. But are ids as expressions and
aggregation mutually exclusive? I wonder if a careful design make
sure that ids are unique even if they're in a group of RDCs, which
might be useful if that pattern appeared over and over, with enough
differences that composition wouldn't work. Just a thought. In any
case, I guess my main point is that I don't see how allowing the id
to be an expression harms ability to use RDCs in groups.
Particularly with a spiffy wiki page explaining what to look out for.
Stu
On Aug 3, 2005, at 10:34 PM, Rahul P Akolkar wrote:
> Stu Robertson <sr...@nvisia.com> wrote on 08/03/2005 11:19:07 PM:
>
>> The id attribute of the RDCs does not allow the value to be set via
>> an expression, unlike all other attributes I've found.
>>
>> We're implementing our applications using the simplest possible
>> pattern, where each JSP contains a single RDC. So the JSPs
>> themselves are identical for a given type of RDC. We have quite a
>> few selectOne tags in an average application. The bits that vary
>> between page, in our design, are populated by expressions, getting
>> their values from state stored in the session.
>>
>> The only one causing trouble is the id. I've made the changes to the
>> RDCs we're using, and will be working though any kinks tomorrow. I
>> just wanted to find out if there was a particular reason why this
>> constraint was added, and so maybe anticipate issues with other
>> plumbing bits.
>>
>
> The ID of an RDC is really meant to be an XML ID, unique to the
> document.
> While in your use case, I understand that this will be clean,
> opening up
> the IDs completely such that they can be expressions probably opens
> a can
> of worms:
>
> A) It becomes harder to determine if there are duplicate IDs
> B) The expression may evaluate to an empty string
> C) Group DM strategies such as the RuleBasedDirectedDialog or
> SCXMLDialog
> probably become unusable
>
> It might be worthwhile brainstorming approaches for the "page level
> templating" that you mention above. I can't think of an elegant
> solution
> off-hand.
>
>
>>
>> Thanks,
>>
>> Stu
>>
>
> -Rahul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [RDC] setting rdc ids at runtime
Posted by Rahul P Akolkar <ak...@us.ibm.com>.
Stu Robertson <sr...@nvisia.com> wrote on 08/03/2005 11:19:07 PM:
> The id attribute of the RDCs does not allow the value to be set via
> an expression, unlike all other attributes I've found.
>
> We're implementing our applications using the simplest possible
> pattern, where each JSP contains a single RDC. So the JSPs
> themselves are identical for a given type of RDC. We have quite a
> few selectOne tags in an average application. The bits that vary
> between page, in our design, are populated by expressions, getting
> their values from state stored in the session.
>
> The only one causing trouble is the id. I've made the changes to the
> RDCs we're using, and will be working though any kinks tomorrow. I
> just wanted to find out if there was a particular reason why this
> constraint was added, and so maybe anticipate issues with other
> plumbing bits.
The ID of an RDC is really meant to be an XML ID, unique to the document.
While in your use case, I understand that this will be clean, opening up
the IDs completely such that they can be expressions probably opens a can
of worms:
A) It becomes harder to determine if there are duplicate IDs
B) The expression may evaluate to an empty string
C) Group DM strategies such as the RuleBasedDirectedDialog or SCXMLDialog
probably become unusable
It might be worthwhile brainstorming approaches for the "page level
templating" that you mention above. I can't think of an elegant solution
off-hand.
>
> Thanks,
>
> Stu
-Rahul