home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Book HomeActionScript: The Definitive GuideSearch this book

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:

  1. Flash receives data as user input.

  2. Flash prepares data for submission to the web server (collects and validates variables).

  3. Flash sends data to the web server via HTTP (or, optionally, HTTPS).

  4. The web server receives data, passes it to a server-side data-handling application (e.g., Perl script, PHP script, Cold Fusion, or ASP).

  5. The data-handling application parses and processes submitted data.

  6. The data-handling application passes results to the web server, which sends results to Flash.

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

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.