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
Therefore, a functioning Flash form requires:
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
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.
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.
Copyright © 2002 O'Reilly & Associates. All rights reserved.