Copyright © 2003 O'Reilly Media, Inc. All Rights Reserved. Flash Remoting: The Definitive Guide By Tom Muck September 2003 ISBN: 0-596-00401-X http://www.oreilly.com/catalog/flashremoting/ Available from booksellers or direct from O'Reilly Media, www.oreilly.com.
This content is excerpted from the above-named O'Reilly publication, with permission, by agreement with ActionScript.org.

There are at least two different approaches to programming in ActionScript 1.0: object-oriented programming and procedural programming. Both have their strengths and weaknesses. You could add a third group of programmers as well: those who program procedurally and use OOP concepts in their applications. This section will show some ways of doing things with Flash Remoting using these approaches.

Procedural Programming

Procedural programming, also known as top-down programming, uses techniques that have been around since the beginning of computer programming. With procedural programming, you write code from beginning to end and call functions when they're needed. Assembly language is an example of procedural programming. There is nothing inherently wrong with procedural programming, yet it has fallen out of favor with the advent of OOP.

Task-oriented

Procedural programming focuses on the tasks. Using an example of the Products database from the earlier chapters, a procedural program asks the question "what has to be done?" and then proceeds to do it. For example, the code might follow like this (in pseudocode):

1. Initialize movie
2. Call remote methods to populate UI
3. Display results
4. Wait for user input
5. If "add" is clicked, show the addProduct screen
6. If "search" is clicked, call the remote method searchProducts( )

Each section of the program (addProduct, searchProducts( ), etc.) would contain more code that executes sequentially, with conditional logic to branch off into other areas of the program.

ActionScript 1.0 promotes the use of procedural programming by the very nature of the ECMA-262 specification. ECMA-262 is not a true object-oriented specification, but it does allow for OOP. It's a very loose language in that it does not require entry points, strict datatyping, class definitions, or even variable declaration. That does not make procedural programming bad; it just means you have to structure your code to make it modular and maintain organization as you do so. One programming flaw in a program can have consequences further down the line. Because the code is executed sequentially, each line of code depends on what comes before it.

TIP: ActionScript 2.0, based on ECMAScript 4 and supported in Flash 2004 and Flash Pro, is geared more toward object-oriented programming, requiring strict typing, formal class declarations, and other constructs familiar to Java programmers. However, ActionScript 1.0 (the version supported by Flash MX) is still supported in Flash 2004 and Flash Pro. ActionScript 1.0 is not strictly case-sensitive in Flash Player 6. However, when exporting for Flash Player 7, ActionScript 1.0 is strictly case-sensitive, as is ActionScript 2.0.

Event-driven

Flash also operates as an event-driven application, and event-driven applications are procedurally oriented. When the movie loads, all of the code in the movie is executed (depending on the timeline, of course). Flash then waits for user input. The user input triggers events that can be trapped with event handlers. These event handlers become named functions when you're using procedural programming:

myButton_pb.setClickHandler("getProducts");
function getProducts( ) {
 myService.getProducts( );
}

When you're using procedural programming in a Flash Remoting application, it becomes even more important to keep the code structured and clean. A procedural program can quickly turn into spaghetti code if the program lacks structure and organization. That said, a procedural program can also be well-constructed and function perfectly.

Result handlers in procedural programming

When dealing with remote services, you have several choices in how you handle the results. The simplest and most documented way of retrieving results is to name a function using the remote method name with an appended _Result or _Status. Generally, a procedural approach would utilize this method:

myService.loginUser(user_txt.text, pwd_txt.text);
loginUser_Result = function (result) {
 if (result == true) {
 trace("User logged");
 } else {
 trace("User not logged");
 }
};

This method is simple, direct, and effective. It is self-documenting, because the remote method name is used in the naming of the callback function. However, it does become cumbersome when dealing with many remote calls. I would not discourage someone from using it, but I would not consider it a best practice. That said, there is nothing wrong with using this technique if you feel comfortable using it.

Procedural example

Example 12-3 is an example of a procedural program with structure.

Example 12-3. A procedural approach to the HelloUser program

#include "NetServices.as"
// Set up variables for the URL and service paths
var myURL = "http://localhost/flashservices/gateway";
var servicePath = "com.oreilly.frdg.HelloUser";

// Connection hasn't been initialized; create connection and service objects
if (initialized == null) {
 initialized = true;
 NetServices.setDefaultGatewayURL(myURL);
 var myConnection_conn = NetServices.createGatewayConnection( );
 var service = myConnection_conn.getService(servicePath, this);
}
// Set up the callback function to handle mouseclicks
submit_pb.setClickHandler("callSayHello");

// Call the service when the user clicks the Submit button
function callSayHello ( ) {
 var user_name = userName_txt.text;
 if (user_name == "") {
 user_name = "User";
 }
 service.sayHello(user_name);
}

// Set up <em>onResult</em> and <em>onStatus</em> event handlers
function sayHello_Result (myResults) {
 results_txt.text = myResults;
}

function sayHello_Status (myError) {
 results_txt.text = myError.description;
}
// Set the system status to be handled by the method status handler as well
System.onStatus = sayHello_Status;

The procedural style mixes the user interface logic (inside the sayHello_Result( ) function) and is executed from the top down. Events that are triggered (such as when the submit_pb button is clicked) are handled by named functions. Events returned by a remote service are handled by functions, sayHello_Result( ) and sayHello_Status( ), that are named after the calling method.

A procedural program such as this can easily grow into spaghetti code if you are not careful. Even in this simple example, the results_txt field is referenced in several places. If something were to change in the interface, you would have to find all of your user interface references and change them manually.

A better option is to use a custom responder object, as discussed in Chapter 4. Some of the more flexible options are shown in Section 12.7.2.