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 Shane Smith <sa...@gmail.com> on 2005/08/04 00:58:19 UTC
RDC's - running code before submit
Folks,
I'd like to suggest the following addition to RDC's and see what is
thought of it. In many cases, voice applications will have to perform
some sort of client side code prior to submitting back to the server.
Yes, I realize that the whole idea is to keep logic on the server
side, and this isn't specifically breaking that rule.
For exmaple:
The echo attribute in many of the rdc's will help confirm for the
caller their selection. The problem is that it requires a round trip
to the server to happen. My requirement is currently that an audio
cue be played when a grammar is matched. Normally, this round trip
wouldn't be a problem, but... I use fetchaudio, fetchaudiodelay, and
fetchaudiominimum attributes of vxml. I need an audio cue to be
played prior to any fetching audio, as even if the http round trip
takes 50ms, I'm cued up to play a full 2 seconds of audio. Now I
could programatically turn this property off and on, but I think I
have a more elegant solution, that will also appeal to a wider
audiance.
In fsm-input.tag, I have the following code:
<filled>
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/filled-pre-submit-list/*"/>
<c:if test="${!model.skipSubmit}">
<script src="${pageContext.request.contextPath}/.grammar/nbest.js"/>
<var name="${model.id}ResultNBest" expr="serializeNBest()"/>
<submit next="${model.submit}" method="post"
namelist="${model.id}ResultNBest"/>
</c:if>
</filled>
The addition is:
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/filled-pre-submit-list/*"/>
By locating this inside the filled, but before the submit, I can code
vxml in the config file for output at runtime. Here is a snippet from
my config:
<filled-pre-submit-list>
<prompt bargein="false">
<audio src="selection-made.vox"/>
</prompt>
</filled-pre-submit-list>*"/>
But, I'm not limited with prompts! Look at the xpath locator portion.
Other rdc:get-configuration's specifically look for a certian child,
for example:
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/help-list/help"/>
I'm actually prevented from using anything but <help> inside my
<help-list>. Now, while this is usually the case, I think we still
ought to let a developer add something else in if they want to.
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/help-list/*"/>
It's a requirement with the <filled-pre-submit-list> though, as I may
want to set a variable, run javascript, play an audio file or <prompt
bargein="false">OK got it</prompt> prompt. Actually, the full list of
possibilities is:
<assign> <audio> <clear> <disconnect> <enumerate> <exit> <goto> <if>
<log> <prompt> <reprompt> <return> <script> <submit> <throw> <value>
<var>
All are valid children of <filled>. Yes, the developer now has the
opportunity to break the 'style' of RDC's (prompt, get input, go back
to the server) but also allows for much more robust applications, such
as a simple audio cue signaling I've heard something. When you mix
this into fetchaudio properties, you can see why a server round-trip
for an audio prompt is unworkable.
Thanks, and thoughts?
-Shane Smith
---------------------------------------------------------------------
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
[RDC] setting rdc ids at runtime
Posted by Stu Robertson <sr...@nvisia.com>.
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's - running code before submit
Posted by Rahul P Akolkar <ak...@us.ibm.com>.
Stu Robertson <sr...@nvisia.com> wrote on 08/03/2005 11:39:13 PM:
> I noticed we crossed paths over the ether!
>
> Shane and I will implement everything we've brought up. We're setup
> so we'll be able to submit patches against the RDC dev trunk. Still
> need to check out the new bugzilla presence, but that shouldn't be a
> problem. We're going to bounce quite a few design ideas around on
> the list, both as a sanity check and also in an attempt to make
> enhancements we need useful for the library themselves. Please
> challenge the need for things we bring up, as well as the
> implementation. We're doing the same on our end.
<snip/>
Definitely, please don't mind me challenging any need(s) either ;-) In
some cases, its hard to get the really corner cases into a public
distribution, just in terms of code manageability. But, you own your
copies after all.
>
> Btw, I really wish there were a bitkeeper-like way of comparing
> between svn repositories...any suggestions on this would be much
> appreciated. Right now I've made a local svn copy of the current RDC
> trunk. We're making changes against our local copy, and can generate
> patches against that. But obviously that breaks down over time as
> RDCs evolve - assuming not all of our patches make it in that is ;-)
<snap/>
Yes, this will be interesting, lets just assume the more difficult case
where you end up with a local copy. First, as long as separate bugzilla
entries are made for every bug/enhancement, we can track each outcome
separately. Then, I think you can create a local branch in SVN, using a WC
to WC copy (not sure). Finally, there are probably some good three-way
diff/merge tools out there.
-Rahul
Re: RDC's - running code before submit
Posted by Stu Robertson <sr...@nvisia.com>.
I noticed we crossed paths over the ether!
Shane and I will implement everything we've brought up. We're setup
so we'll be able to submit patches against the RDC dev trunk. Still
need to check out the new bugzilla presence, but that shouldn't be a
problem. We're going to bounce quite a few design ideas around on
the list, both as a sanity check and also in an attempt to make
enhancements we need useful for the library themselves. Please
challenge the need for things we bring up, as well as the
implementation. We're doing the same on our end.
Btw, I really wish there were a bitkeeper-like way of comparing
between svn repositories...any suggestions on this would be much
appreciated. Right now I've made a local svn copy of the current RDC
trunk. We're making changes against our local copy, and can generate
patches against that. But obviously that breaks down over time as
RDCs evolve - assuming not all of our patches make it in that is ;-)
Stu
On Aug 3, 2005, at 10:18 PM, Rahul P Akolkar wrote:
> Stu Robertson <sr...@nvisia.com> wrote on 08/03/2005 11:07:24 PM:
>
>> This provides a nice hook for all sorts of things developers might
>> want to do when a grammar is matched. One of the challenges we're
>> bumping into is that without this sort of hook, "app space" is quite
>> limited to functionality directly implemented in the base RDCs. This
>> approach is appealing because it makes adding "earcons" trivial (in
>> the simple case; we're using it with dynamic config files with earcon
>> includes), and extending RDCs with custom behaviors possible (per-
>> instance client-side validation for instance...or again generalized
>> in app-space through config file includes, as we intend).
>>
>> Anyway, since it's optional and adds needed flexibility it at least
>> fits the general description of things that are nice to support in a
>> framework like RDCs. We've bounced around different approaches, and
>> this one seems interesting to us. We're very interested in input.
>>
>
> Just replied to the original email in this thread, this will be a good
> addition. Would you (or Shane) like to sketch up a list of tasks/
> changes
> w.r.t to the code? We can then divide up the work, so it'll get done
> sooner.
>
>
>>
>> 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's - running code before submit
Posted by Rahul P Akolkar <ak...@us.ibm.com>.
Stu Robertson <sr...@nvisia.com> wrote on 08/03/2005 11:07:24 PM:
> This provides a nice hook for all sorts of things developers might
> want to do when a grammar is matched. One of the challenges we're
> bumping into is that without this sort of hook, "app space" is quite
> limited to functionality directly implemented in the base RDCs. This
> approach is appealing because it makes adding "earcons" trivial (in
> the simple case; we're using it with dynamic config files with earcon
> includes), and extending RDCs with custom behaviors possible (per-
> instance client-side validation for instance...or again generalized
> in app-space through config file includes, as we intend).
>
> Anyway, since it's optional and adds needed flexibility it at least
> fits the general description of things that are nice to support in a
> framework like RDCs. We've bounced around different approaches, and
> this one seems interesting to us. We're very interested in input.
Just replied to the original email in this thread, this will be a good
addition. Would you (or Shane) like to sketch up a list of tasks/changes
w.r.t to the code? We can then divide up the work, so it'll get done
sooner.
>
> Stu
-Rahul
Re: RDC's - running code before submit
Posted by Stu Robertson <sr...@nvisia.com>.
This provides a nice hook for all sorts of things developers might
want to do when a grammar is matched. One of the challenges we're
bumping into is that without this sort of hook, "app space" is quite
limited to functionality directly implemented in the base RDCs. This
approach is appealing because it makes adding "earcons" trivial (in
the simple case; we're using it with dynamic config files with earcon
includes), and extending RDCs with custom behaviors possible (per-
instance client-side validation for instance...or again generalized
in app-space through config file includes, as we intend).
Anyway, since it's optional and adds needed flexibility it at least
fits the general description of things that are nice to support in a
framework like RDCs. We've bounced around different approaches, and
this one seems interesting to us. We're very interested in input.
Stu
On Aug 3, 2005, at 5:58 PM, Shane Smith wrote:
> Folks,
>
> I'd like to suggest the following addition to RDC's and see what is
> thought of it. In many cases, voice applications will have to perform
> some sort of client side code prior to submitting back to the server.
> Yes, I realize that the whole idea is to keep logic on the server
> side, and this isn't specifically breaking that rule.
>
> For exmaple:
>
> The echo attribute in many of the rdc's will help confirm for the
> caller their selection. The problem is that it requires a round trip
> to the server to happen. My requirement is currently that an audio
> cue be played when a grammar is matched. Normally, this round trip
> wouldn't be a problem, but... I use fetchaudio, fetchaudiodelay, and
> fetchaudiominimum attributes of vxml. I need an audio cue to be
> played prior to any fetching audio, as even if the http round trip
> takes 50ms, I'm cued up to play a full 2 seconds of audio. Now I
> could programatically turn this property off and on, but I think I
> have a more elegant solution, that will also appeal to a wider
> audiance.
>
> In fsm-input.tag, I have the following code:
> <filled>
> <rdc:get-configuration xml="${model.configuration}"
> locator="/config/${stateNode}/filled-pre-submit-list/*"/>
> <c:if test="${!model.skipSubmit}">
> <script src="${pageContext.request.contextPath}/.grammar/
> nbest.js"/>
> <var name="${model.id}ResultNBest" expr="serializeNBest()"/>
> <submit next="${model.submit}" method="post"
> namelist="${model.id}ResultNBest"/>
> </c:if>
> </filled>
>
> The addition is:
> <rdc:get-configuration xml="${model.configuration}"
> locator="/config/${stateNode}/filled-pre-submit-list/*"/>
>
> By locating this inside the filled, but before the submit, I can code
> vxml in the config file for output at runtime. Here is a snippet from
> my config:
>
> <filled-pre-submit-list>
> <prompt bargein="false">
> <audio src="selection-made.vox"/>
> </prompt>
> </filled-pre-submit-list>*"/>
>
> But, I'm not limited with prompts! Look at the xpath locator portion.
> Other rdc:get-configuration's specifically look for a certian child,
> for example:
>
> <rdc:get-configuration xml="${model.configuration}"
> locator="/config/${stateNode}/help-list/help"/>
>
> I'm actually prevented from using anything but <help> inside my
> <help-list>. Now, while this is usually the case, I think we still
> ought to let a developer add something else in if they want to.
>
> <rdc:get-configuration xml="${model.configuration}"
> locator="/config/${stateNode}/help-list/*"/>
>
> It's a requirement with the <filled-pre-submit-list> though, as I may
> want to set a variable, run javascript, play an audio file or <prompt
> bargein="false">OK got it</prompt> prompt. Actually, the full list of
> possibilities is:
>
> <assign> <audio> <clear> <disconnect> <enumerate> <exit> <goto> <if>
> <log> <prompt> <reprompt> <return> <script> <submit> <throw> <value>
> <var>
>
> All are valid children of <filled>. Yes, the developer now has the
> opportunity to break the 'style' of RDC's (prompt, get input, go back
> to the server) but also allows for much more robust applications, such
> as a simple audio cue signaling I've heard something. When you mix
> this into fetchaudio properties, you can see why a server round-trip
> for an audio prompt is unworkable.
>
> Thanks, and thoughts?
>
> -Shane Smith
>
> ---------------------------------------------------------------------
> 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's - running code before submit
Posted by Rahul P Akolkar <ak...@us.ibm.com>.
On 8/3/05, Shane Smith <sa...@gmail.com> wrote:
> Folks,
>
> I'd like to suggest the following addition to RDC's and see what is
> thought of it. In many cases, voice applications will have to perform
> some sort of client side code prior to submitting back to the server.
> Yes, I realize that the whole idea is to keep logic on the server
> side, and this isn't specifically breaking that rule.
>
<snip/>
>
> All are valid children of <filled>. Yes, the developer now has the
> opportunity to break the 'style' of RDC's (prompt, get input, go back
> to the server) but also allows for much more robust applications, such
> as a simple audio cue signaling I've heard something. When you mix
> this into fetchaudio properties, you can see why a server round-trip
> for an audio prompt is unworkable.
>
> Thanks, and thoughts?
<snap/>
Sounds very good. Extending the config to do more has been on the to-do
list. I won't get any cycles this week, do you want to propose a patch to
fsm-* tag files? We now have a RDC Taglib entry in bugzilla [
http://issues.apache.org/bugzilla/ ] - if you do propose a patch, please
file under Taglibs and choose component "RDC Taglib".
On a related note, as pointed out briefly in the earlier thread, there is
no binding 'style' of RDCs or insistence that there should be a round trip
every so often. The binding RDC bits are the public contracts which allow
aggregation and composition, more on that is here [
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials
].
>
> -Shane Smith
-Rahul