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's - running code before submit
Date Thu, 04 Aug 2005 03:07:24 GMT
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


Mime
View raw message