How
Much is that Pizza, Anyway?
Welcome
to First Words, VoiceXML Review's column that teaches
you about VoiceXML and how you can use it. We hope you
enjoy the lesson.
Last
month, we looked at a few different ways of gathering
input from the user, and at some useful ways to tailor
the interface so that it is useful and non-repetitive.
Now we're going to look at a few different server-side
solutions that will enable us to do something useful
with the input we've collected.
As
we've discussed in previous columns, one of the true
strengths of VoiceXML is the fact that it follows the
well-understood web model of input gathering and form
submission. Although you can build interesting applications
using static VoiceXML pages, things really get interesting
when you combine VoiceXML with the many dynamic page
generation technologies that are available today. Some
of these include Java Server Pages (JSP), Active Server
Pages (ASP), ColdFusion, PHP, and Perl. What is the
interface to these technologies? That is the question
we'll deal with this month.
At
the tail end of the pizza application, which we've been
building, we had the following snippet of VoiceXML:.
<block>
One moment while I add
<value expr="orderCount"/>
<value expr="orderItem"/>
to your order.
<submit next="/cgi-bin/pizzaCart.pl
namelist="orderItem orderCount"/>
<block>
|
This
would be invoked whenever we have completed our processing
of the two form fields. We can make this a little smarter
by changing it to this:
<filled mode="all" namelist="orderCount orderItem">
One moment while I add
<value expr=orderCount"/>
<value expr="orderItem"/>
to your order.
<submit next="/cgi-bin/pizzaCart.pl"
namelist="orderItem orderCount"/>
</filled>
|
What's
the difference? The first example (within the block
container) will execute regardless of the result of
the field input collection elsewhere in the form.
It is possible that our requests for an order have
gone unheeded, and we have finished our field input
collection unsuccessfully. In the second example,
we've changed to a form-level filled tag. When you
place a filled component at the form level, it will
by default be executed when all field items have been
successfully gathered. In our case, this means that
we've gotten an orderItem and an orderCount from the
user. We've used both legal attributes for the form-level
filled tag: mode and namelist. You can control which
field items are collected using these tags. The namelist
specifies which field items we're interest in, and
mode specifies whether we have to have collected all
or any of them. In this case, we've just entered the
defaults (so we could have omitted the attributes
entirely).
The
most interesting thing here though is the submit tag.
When a submit is executed, the VoiceXML interpreter
does the following things:
- Collects
the field item variables for the form;
- Sends
the contents using a standard HTTP request to the
specified web server URL;
- Receives
the HTTP response from the web server, typically as
the next VoiceXML page in the application.
The
field variable data is sent to the URI specified by
the next attribute. The HTTP method used for submitting
the data can be either GET or POST, and is specified
by the method attribute. The form field item data is
encoded in the same way as it would be if you filled
out a form in your visual web client, and submitted
that data to a web server. The available formats typically
include form-url-encoded, and multipart-form. You can
select between these using the enccode attribute of
submit. The submit tag has a number of other attributes
related to caching (we're going to talk about caching
next month).
back
to the top
Copyright
© 2001 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE
Industry Standards and Technology Organization (IEEE-ISTO).
|
