Adobe Flash Professional CS3 - Manual (Page 483)

FLASH CS3
User Guide
477
In both cases, you could receive complex data structures, such as arrays, objects, or record sets, which you must parse
and bind appropriately.
Using error handling and debugging
Your application needs to be robust enough to anticipate certain errors and handle them accordingly.
One of the best ways to perform error handling in ActionScript 2.0 is to use the try-catch-finally blocks that let
you throw and catch custom errors. By creating custom error classes, you can reuse code throughout your application
without having to rewrite error handling code. For more information on throwing custom errors, see the
Error class
in ActionScript 2.0 Language Reference. For more information on try-catch-finally blocks, see
try..catch..finally in ActionScript 2.0 Language Reference.
In ActionScript 3.0, use the flash.errors class to catch errors.
For more information, see “Handling synchronous errors in an application” in Programming ActionScript 3.0.
Organizing files and storing code
Consider the following guidelines before you start organizing files and storing code:
• Do you divide the SWF file into multiple SWF files, and, if so, how should they interact?
• What assets can you share across SWF files?
• What files do you dynamically load?
• How and where do you store ActionScript?
When you develop an application, store your server-side code and files in a logical directory structure, similar to
those in an ActionScript package. Arrange your code this way to keep it well organized and reduce the risk of the
code being overwritten.
For larger applications, encapsulate client-server communication and services in classes. When you use classes, you
benefit in the following ways:
• You can reuse the code in more than one SWF file.
• You can edit code in a central place, and update all SWF files by republishing them.
• You can create a single API that can manipulate different UI elements or other assets that perform similar
functions.
Using the MVC design pattern
The MVC design pattern is used to separate the information, output, and data processing in the application. The
application is divided into three elements: model, view, and controller; each element handles a different part of the
process.
The model Incorporates the data and rules of the application. Much of the application’s processing occurs in this part
of the design pattern. The model also contains any components (such as CFCs, EJBs, and web services), and the
database. Data returned is not formatted for the interface (or front end) of the application in this part of the process.
The returned data can be used for different interfaces (or views).
The view Handles the front end of the application (the interface with which the user interacts), and renders the
model’s contents. The interface specifies how the model’s data is presented and outputs the view for the user to use,
and lets the user access or manipulate the application’s data. If the model changes, the view updates to reflect those
changes by either pushing or pulling data (sending or requesting data). If you create a hybrid web application (for