 | ActionScript: The Definitive Guide |  |
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".
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.
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.
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 loadVariables( ) function, described later in this chapter
The XML class's send( ) and sendAndLoad( ) methods, described in Part III, "Language Reference"
The global function getURL( ), described in Part III, "Language Reference"
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.
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.
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.