Chapter 17. Flash Forms
Interactivity on
the Web reaches perhaps its loftiest status in
the guise of the fill-in form. Okay, that might sound a little
hyperbolic, but it's not meant to be. Forms may appear trivial
on the surface, but they are at the heart of online communities (chat
rooms and message boards), the persistence of data (personalization),
and of course, the saliva-in-the-jaws-of-business, e-commerce (buying
and selling online).
Flash 4 was the first version of Flash to include forms support.
Since then, Flash has gained many powerful means of communicating
with a server. This chapter explores the basics of using forms in
Flash, from capturing user input and displaying output within Flash,
to sending data to a server and receiving the server's
response. More advanced topics, such as XML handling, are covered in
Part III, "Language Reference".
17.1. The Flash Form Data Cycle
Before we
delve into the particulars, let's take a macroscopic look at
the typical steps in a form submission process:
Flash receives data as user input. Flash prepares data for submission to the web server (collects and
validates variables). Flash sends data to the web server via HTTP (or, optionally, HTTPS). The web server receives data, passes it to a server-side
data-handling application (e.g., Perl script, PHP script, Cold
Fusion, or ASP). The data-handling application parses and processes submitted data. The data-handling application passes results to the web server, which
sends results to Flash. Flash stores and optionally displays results.
Therefore, a functioning Flash form requires:
A frontend (what the user sees) Some Flash scripting that submits the form's contents to a
server-side script or application A server-side script or application Some Flash scripting that handles data returned from the server
Let's examine these components in a little more detail.
17.1.1. Flash Client-Side User Input
To supply input,
users typically type text into text fields and then click the
form's Submit button. Only text fields are supplied as prebuilt
form components; we have to build everything else, including the
Submit button, manually (as we'll see later). See Section 18.2, "User-Input Text Fields" in Chapter 18, "On-Screen Text Fields", for
information on text fields.
Because Flash has a full scripting language, you can create
intelligent forms that preprocess data before it's submitted to
the server. We validate the user's entries before sending them
to the web server to ensure that our data-handling application always
receives usable data. Common validations include checking that all
required fields have been filled out and verifying that the correct
type of data has been entered. For example, an email address should
include a name, followed by an @ symbol, followed by a domain name.
17.1.2. Transmitting Data for Server-Side Processing
Once our data is validated, we may safely
pass it to the web server. ActionScript provides several tools for
transferring form-based data to a web server:
The web server passes the Flash data to the server-side
application that will process the data, typically a middleware
database (e.g., Allaire's ColdFusion or Microsoft's ASP)
or a CGI script (e.g., a Perl or PHP script or a Java servlet).
In describing the web client/server data cycle, we make a point of
distinguishing between the web server and a data-handling
application. Often, this distinction is implicit -- the client
always has to make an HTTP request in order to send data to the
data-handling application, so it naturally follows that a web server
is involved. In Flash form development, however, we must remain aware
of the invisible handoff between the web server and the data-handling
application. Data moves from Flash to the server either on the end of
a URL (using GET) or in a stream of variable names and values (using
POST). When a web server error is encountered, Flash does not display
the HTTP error messages that the server sends (as a browser would).
For example, if the web server can't find a CGI script, it
sends a "404 Not Found" message, but Flash doesn't
display it. Similarly, if a CGI script's permissions
aren't set correctly, we don't see any execution-failure
error message. In order to isolate client/server problems when
working with Flash, it's useful to monitor the web
server's HTTP error log while attempting to run scripts. You
may find that the web server is trying to tell you something that
Flash can't express.
17.1.3. The Data-Handling Application
Upon receiving a body of data, the
data-handling application must parse it (i.e.,
interpret it intelligently and, if necessary, split it out into
manageable pieces). After the data is parsed, it can be manipulated
in an endless number of ways by the server application. Usually data
processing involves saving content to a database or flat text file
for future retrieval.
Once data processing is complete, the data-handling application
produces a result to pass back to Flash. That result can be anything
from a simple confirmation message ("Thank you for submitting
your information") to a list of records from a database or the
current price of a product.
The application passes the result to the web server, which will
forward it on to Flash for storage or display.
TIP
Data-handling application
developers should note that their application must set the MIME type
of the result to "application/x-www-urlform-encoded". If
that MIME type is missing, the result will likely be unusable when it
reaches Flash.
17.1.4. Flash Receives and Interprets Results
We're nearing the end of the Flash form
cycle, but we're not done yet. For one thing, we have to make
sure that Flash waits patiently while the server-side application
processes the data and transmits the result. Consider a movie that
looks up stock prices. The user enters a stock ticker symbol and
clicks the Get Stock Price button. Before the price can be displayed,
the stock-retrieval application must identify and return the price.
While the movie is waiting, it displays a "Loading"
message. When the price is received, the movie springs back into
action.
Data received by Flash in response to a loadVariables(
) invocation is stored in a specified target clip or
level. Once that data has been received, the Flash form cycle is
complete, and we're free to do whatever we like with our
precious, well-traveled bytes of content. Let's now put our
knowledge to practice by creating a simple fill-in form.
 |  |  | | 16.9. Onward! |  | 17.2. Creating a Flash Fill-in Form |
Copyright © 2002 O'Reilly & Associates. All rights reserved.
|
