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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
