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).
|
