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 and 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 the submitted data.
The data-handling application passes the results to the web server, which sends the results to Flash.
Flash stores and, optionally, displays the results.
Therefore, a functioning Flash form requires:
A front end (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 in a little more detail.
To
supply text-based
input, users enter text into on-screen
text fields. In ActionScript, an on-screen text field corresponds to
an instance of the TextField class, which we use
to access the field's data. Users can also provide
input using interface elements such as pull-down menus, radio
buttons, and checkboxes. Prior to Flash MX, these typical form
elements were created from scratch by the developer. Flash MX
introduced prebuilt form widgets called the Flash UI
Components: CheckBox, ComboBox, ListBox, PushButton,
RadioButton, ScrollBar, and ScrollPane. These components are not a
native part of ActionScript; they are sophisticated movie clips that
come with the Flash MX authoring tool. To learn how to use the Flash
MX UI Components, see Help 
Tutorials
Introduction to Components Tutorial. For a summary
of the Flash UI Components' properties and methods,
see Appendix G.
Once a user's input has been collected, it should be validated before it's sent to the server. This ensures that our server-side 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 the input data is validated, we can safely pass it to the web server. ActionScript provides several tools for transferring form-based data to a web server:
The LoadVars class, described later in this chapter
The loadVariables( ) function (used in Flash 4 and Flash 5, but superceded by LoadVars in Flash MX)
The XML class's send( ) and sendAndLoad( ) methods, described in the Language Reference
The getURL( ) global function, also described in the ActionScript Language Reference
The web server passes the Flash data to a server-side application (e.g., Macromedia ColdFusion or Microsoft ASP) or a CGI script (e.g., a Perl or PHP script, or a Java servlet).
When 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 this message. Similarly, if a CGI script's permissions aren't set correctly, Flash doesn't display an execution-failure error message. In order to isolate client/server problems when working with Flash, monitor the web server's HTTP error log while attempting to run scripts. The web server log will tell you things that Flash won't. For information on problems associated with the HTTP POST method in Flash, see Appendix F.
Upon receiving data, the data-handling application must parse it (i.e., it must interpret the data intelligently and split it into manageable pieces). The parsed data can be manipulated in endless ways by the server application, such as saving it 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. The result can be a simple confirmation message (e.g., "Thank you for submitting your information"), a list of records from a database, or the current price of a product.
The application passes the result to the web server, which forwards it on to Flash for storage or display.
If the response from your server application uses characters above Unicode 127 (i.e., high ASCII characters or characters outside Latin 1), you should use UTF-8-encoded XML to send your data. It is also possible to encode a stream of variables in UTF-8 for use by the LoadVars class, but not all server-side applications can specify that encoding. As a last resort, if you know that the server's code page (i.e., its primary character set) will definitely match the code page of the Flash client system, you can use System.useCodepage to force Flash Player 6 to interpret characters using the system's current code page rather than Unicode (this is, in fact, Flash 5's only supported behavior). For more information, see Section 4.5.1 and System.useCodepage in the Language Reference.
We're nearing the end of the Flash form cycle, but we're not done yet. 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 share price. While the movie is waiting, you should display a "Loading" message. When the share price is received (i.e., once the data finishes loading), Flash triggers the target LoadVars object's onLoad( ) handler, where we can interpret the data and display it to the user. (Data received via LoadVars.sendAndLoad( ) is stored in the target LoadVars object.)
The Flash form cycle is complete, and we're free to do whatever we like with our precious, well-traveled bytes of content. Now let's put our knowledge to practice by creating a simple fill-in form.
