The browsing portion of the user interface contains the category view. The category view contains 5 top-level pet categories with each category having several variants of pets associated with it.

As you click an individual pet category, the pet's picture will animate to the lower-left portion of the page and list all variants of the pet category. As the product changes and animates, the data for the product is being retrieved from the server without the page reloading. This is a powerful feature of the Macromedia Flash MX client. Often, the data is returned before the animation completes.

The Pet Market application includes nearly 50 pictures of animals. Each bitmap is optimized for size and image quality in Macromedia Fireworks MX. The 50 pet images were optimized using the batch process function of Macromedia Fireworks MX

Because Macromedia Flash MX supports loading JPEG images on the fly, it is not necessary to download all these pictures before interacting with the SWF. Only the pictures that are requested by the client are downloaded.

You will also notice that as you select a specific pet from the pet category, the homepage section of the Pet Market application is dynamically updated with your selection's name, picture, and description. And like most other online stores, you can select an item and add it to a shopping cart as shown below:

Some of the major advantages the checkout forms in the Pet Market application have over a set of HTML forms are:

Masking images
Macromedia Flash MX can add distinctive styles to normal images. For example, the pet pictures in the upper right-hand corner are normal rectangular images that have an oval mask applied to them on the client side by Macromedia Flash MX. Such functionality makes it very easy to add additional pet images without having to process the pet image before publishing the image on the server. If you wanted to accomplish this in HTML, you would have to edit each individual image and apply the mask.

As you navigate the Pet Market application, you may notice how fast the browsing experience is. All the product browsing data is coming from the server through the AMF (Action Message Format) protocol. This provides the Macromedia Flash MX client with native ActionScript objects to use for displaying data. Why are native ActionScript objects important? Because you don't have to convert to and from XML format.

Macromedia Flash MX allowed the developers of the Pet Market application to collapse what would have been a multi-page HTML purchase experience into a multi-step experience that retains context and access to previously entered information without page refreshes. Pre-validation of form data can be performed by logic in the client that, unlike JavaScript-based approaches, is independent of browser implementation differences. And server-side validation (as in the case of creating a new user and checking that the username is unique) may be performed without a page refresh. The shopping cart is a persistent element of the overall interface and is completely interactive. Quantities may be edited, items removed and added, all without reloading pages or losing context.

Furthermore, because Macromedia Flash MX is capable of performing many application activities locally, it is often the case that fewer server transactions are necessary. This means that a server can handle a larger load with a Macromedia Flash-based UI when compared to a comparable HTML UI.

ActionScript
The Pet Market application provides a smooth shopping experience for the user. This experience would not be possible without the use of ActionScript. ActionScript is a full fledged, standards-based, object-oriented programming language used in the Macromedia Flash MX authoring environment. ActionScript files (.as and .asr files) can be coded and managed in Macromedia Dreamweaver MX. The Pet Market application uses a sophisticated object-oriented architecture based on a Model-View-Controller design pattern.

The Pet Market application consists of a number of objects created in ActionScript. For example, when the Finch is clicked in the list of birds, ActionScript binds the event to the main browsing and history UI. ActionScript causes a picture of a Finch and its related data to show up on the main screen and also adds a color icon and list item to the list history UI widget.

ActionScript is also used in the Pet Market application when a user browses the application. While browsing, the ActionScript either enables or disables the application elements depending on the current application state. For example, when the shopping cart is collapsed and the user adds an item to it, ActionScript automatically expands the cart to indicate data has been added to the shopping cart.

A third example of ActionScript implementation is credit card validation. All credit card information is validated in Macromedia Flash MX by an ActionScript function.

Some of the advantages of using Macromedia Flash MX UI components for application development are:

The components used in the Pet Market application are:

Component	Description	Example
CheckBox	The CheckBox component lets you add check boxes to Macromedia Flash MX SWFs with a minimum of authoring and scripting.
ComboBox	The ComboBox component lets you add scrollable single-selection drop-down lists to Macromedia Flash MX SWFs with a minimum of authoring and scripting.
IconButton	The IconButton component lets you create a button with a custom icon and look.
ListBox	The ListBox component lets you add single and multiple-selection list boxes to Macromedia Flash MX SWFs.
MessageBox	The MessageBox component lets you add dialog boxes to a Macromedia Flash MX SWF.
RadioButton	The RadioButton component lets you add groups of radio buttons to Macromedia Flash MX documents.
ScrollBar	The ScrollBar component provides functionality for adding vertical and horizontal scrollbars to dynamic and input text fields.

Find out more about the complete set of components available with Macromedia Flash MX at the Macromedia Flash MX Application Development Center.

The Macromedia Flash MX UI components can also be extended to provide your own custom interface elements. In the Pet Market application, the list box was extended 3 different ways:

Macromedia Flash Remoting
Macromedia Flash Remoting links a Macromedia Flash MX client with a ColdFusion MX back-end. This gateway technology connects Macromedia Flash MX components on the client side with server-side application services. Macromedia Flash Remoting enables a Macromedia Flash MX client to interface with remote components running on an application server in an efficient, secure, and reliable way. Macromedia Flash Remoting ships as an integrated feature of ColdFusion MX and JRun 4. Some of the advantages of using this technology are:

For more information on Macromedia Flash Remoting, refer to the Macromedia Flash Remoting page.

Another benefit of this approach is that the Macromedia Flash MX client is not dependent on the service implementation. This means that you can build your prototype service in ColdFusion MX, and transition to a Java or .NET server implementation if desired, with no changes to client code

Other aspects to note
There are no language dependent strings embedded in the Macromedia Flash MX SWFs; all strings shown in the interface come from either a static text file or the server-side "string resources service". Moreover, nearly all of the data is located on the server in the database. This is a great advantage for the Pet Market application because it shows how the Macromedia Flash MX SWF is dynamic and can respond to new products and items without the Macromedia Flash MX SWF having to be rebuilt.

As you begin to examine the source code for the Pet Market application, you will notice there are two layers to the implementation: the client-side Macromedia Flash User Interface and a ColdFusion-based back-end. In addition to the implemented layers, the system consists of Macromedia Flash Remoting, ColdFusion MX, Macromedia Flash MX Player and a third party database. The architecture is presented in the following diagram.

Runtime files
At runtime, the runtime components of the Pet Market application are downloaded at various times to the client browser. The following table lists the different components, their sizes, and the function they perform. (Note “SWF” refers to the compiled Macromedia Flash file format with the file extension “.swf”, while “FLA” refers to the source Macromedia Flash file format with the file extension “.fla”).

ActionScript Overview
Nearly all of the Pet Market application UI logic, including UI animation, is in external ActionScript files. External ActionScript files have the file extension “.as” and can be edited in Dreamweaver MX, Macromedia Flash MX, or any text editor. The FLA files do contain some ActionScript, but that ActionScript consists mainly of calls to functions defined in external ActionScript files. This factoring of the client side ActionScript code makes it easier for multiple developers to work on different parts of the client simultaneously.

Each external ActionScript file contains a comment indicating where it is #included in the FLA. Based on their function, the ActionScript files can be divided into the following categories.

Init Functions
The initialization functions are called from the movie timeline to set up styles and communication (Folder: flash_src/initFunctions).

Utility Functions
The utility functions are functions that don't fit neatly into any of the other categories (Folder: flash_src/utilityFunctions).

Pet Market source code is centered around the Model/View/Controller (MVC) architecture. The MVC architecture is commonly used in UI centric applications as a way of organizing code into classes that handle data (Models), classes that dispatch among UI elements (Controllers), and classes that implement the UI elements (Views).

In Pet Market, the Model classes are the CatalogModel, the CartModel, OrderModel, StringResourcesModel and the UserModel. All the class files are in the ModelControllerClasses folder. Each of these model classes handle Macromedia Flash Remoting calls to the Catalog and Cart gateway services.

The Controller functionality is implemented via the Broadcaster class, which is also defined in the ModelControllerClasses folder. The Broadcaster implements Controller with the addEventListener/listenToBroadcaster function pair. View classes register themselves with the broadcaster by calling addEventListener on a broadcaster object. The broadcaster notifies View classes of new data by calling listenToBroadcaster on registered View classes.

Each of the Model classes above derive from the Broadcaster class which means the classes also function as Controllers and that is why their containing folder is called ModelControllerClasses. The View classes use the ModelControllerClasses to both request data and to be notified when data is available. For example, the CartUI View class registers itself with the CartModel as a listener to the "addCartItem" event. The CartUI can now use the CartModel class in two ways: it can ask the CartModel to add data to the cart on the server (Model functionality) and it can implement the listenToBroadcaster function to be notified when new cart data should be displayed (Controller functionality).

The ViewClasses folder contains classes that govern UI behavior and that also listen to at least one of the ModelController classes. The ViewClasses have been grouped to implement a distinct function area in the Pet Market application. When the function area neatly fits into a parent movie clip, the class code is attached to the MovieClip in the library, otherwise the View Clip is a pure ActionScript object that manages movie clip references. The individual files contain comments explaining which class is the former and which the latter.

Note: the main timeline itself is also a View class and it implements listenToBroadcaster in the mainInit.as file. Having the main timeline as a View class gives all movie clips the ability to communicate with the main timeline without referencing it directly. This is key to the hide/show checkout animations.

Following convention, the layer stack starts with layers that do not contain graphical elements. In particular, there are layers for frame labels and Actions.

While the main.fla does contain nearly all of the ActionScript code, the code is stored in external files ending with the AS extension. When code is in main.fla itself, it is contained in either the "Actions : Class definitions" layer or the "Actions : Function calls" layer. In particular, the "Actions : Class definitions" layer simply contains #includes and the "Actions : Function calls" layers is mostly initialization function calls and timeline- dependent movieclip hiding/showing code. This source code organization is a Macromedia suggested best practice.

One last thing to note about the layer stack: order matters for layers containing graphical elements. The order determines how the content will appear on the stage.

Here's a brief rundown of the timeline.

Frame 1 of layer "Actions : Class definitions" starts with a list of #include files. These #includes are restricted to a frame that executes exactly once. In addition, all of the frame 1 #includes are files that are not associated with Library movie clip symbols.

Frames 1-5 of layer "Actions : Function calls" contain function calls that set up UI style, retrieve application strings, retrieve or generate new user data, and display a welcome message.

Frame 6 ("homeLoading") of layer "Actions : Function calls" sets up the connection to the gateway, registers category and item browsing listeners, and then requests the category list from the gateway. All of these calls are wrapped in an if statement so that they occur exactly once while the SWF runs. Since the listeners have been set up, all future ActionScript will take place in the ViewClasses code, triggered by listenToBroadcaster calls.

Frame 11 ("home") of layer "Actions : Function calls" sets up the widgets on the right hand side of the UI. It contains a call to initWidgets() which in turn initializes the widgets and registers them as listeners to ModelController class events.

Frame 26 ("checkout") of layer "Actions : Function calls" sets up the checkout widget and registers it as a listener. This code is also wrapped in an if statement that ensures the initialization code only executes once.

The back-end of the Pet Market application is implemented using ColdFusion Components. The API is broken into 8 separate API components and 1 common component for functions used by more than 1 API component. The component files are located in the folder named "api". The components are described below:

Catalog Service
The catalog service provides the APIs for browsing the catalog of pets.

Cart Service
The cart service provides the APIs for interacting with a shopping cart (e.g., adding or removing items).

User Service
The user service provides the APIs for creating, updating and getting users.

Address Utility Service
The address utility service provides APIs to assist in creating and validating address items (e.g., postal codes).

Order Service
The order service is an API that simulates the order process. In the Pet Market application, the order service simply deletes a cart. In a real-world implementation, this service would "kick-off" the order fulfillment process.

Credit Card Service
The credit card service is an example of using server-side ActionScript to create an API. This service provides a function to validate a credit card number. Clearly, this is a rudimentary example, as we are not implementing any encryption for the credit card information.

Version Service
The version service provides an API to retrieve version information. This is particularly useful during test phases of the project.

Common
The common component contains functions used by the API components.

Pet Market was designed as an example application to demonstrate the power of Macromedia Flash MX, Macromedia Flash Remoting and Macromedia ColdFusion MX. We concentrated on features that demonstrate the advantages of these technologies. This section addresses topics that are important to a robust production application that were not implemented in the Pet Market application. We deemed these features to be straightforward extensions to the Pet Market example and leave them as an exercise to the reader.

All string resource for the Macromedia Flash UI are stored in the following files:

Examples of how one might approach localization of the Pet Market application can be found in the following files:

User Management
To keep the Pet Market application simple, we did not implement full scale user management functionality. In particular, here are some of the user management related functions that would likely be added in a production application:

Database Maintenance
Pet Market creates records in the database as users shop for and purchase pets. Over time, the database will accumulate extraneous records for items such as carts and users. Ideally, the system would include a process that would periodically review the database and purge items that are no longer necessary. To facilitate such a process, database records would include time-stamps to record when the item was last accessed.

Accessibility
Pet Market is accessible for keyboard navigation but not for screen readers. Consider building in screen reader accessibility features at the design phase utilizing the new accessibility feature in Macromedia Flash MX. To learn more about this new feature, reference "Creating Accessible Content" in the Help menu of Macromedia Flash MX.

Search
The search functionality in Pet Market is quite simplistic. For a commercial deployment, a full-fledged search function would need to handle issues such as word breaks and scoring results. Check out the Verity search features in ColdFusion MX for further ideas on implementing a robust search feature.

Many of the CFC functions depend on database ID values as parameters in order to determine on which objects to operate. Given that there is no authentication for most of the functions (and in some case, since there has been no user account created to authenticate against), these functions could easily be used by a rogue client to modify the carts of other users of the site.

A more secure approach would keep the cart instance in the session, so that it is accessible only by the user on whose behalf it was created. A rogue client would have to guess the session ID of his target in order to use the functions to modify their cart. This doesn't mean the security is perfect, but it puts the responsibility for keeping the cart secure back in its proper place -- on the application server's ability to keep session data secure. Application servers do this in many ways, among them using algorithms to generate session IDs that are very hard to guess.

The same approach would apply for the user data. The database OID would be kept on the server rather than being made available to the Macromedia Flash SWF as part of the returned user object. A user would be required to successfully log in to get or update their user information.

Lastly, like any secure application, it should be served using HTTPS in order to make eavesdropping difficult.

1. You need to decide how much of the application you want to develop for the client and how much you want to develop for the server. It is recommended you place as much of the UI on the client as possible. But keep in mind you do not want to send a lot of data all at once from the server to the client.

   For example, consider the Zip Code validation logic in Pet Market. Zip Code validation must be done at the server, for the simple reason that there are over 40,000 unique Zip Codes. That's way too much data to send to the client to edit one Zip Code.
   
   Similarly, the product hierarchy in the Pet Market is stored on the server. Although the sample database has a relatively small number of products, a real-life application would have a much larger number of items in the product database, making it time-prohibitive to send the complete product hierarchy to the client in this application.

2. When designing your API to communicate between the client and the server, start by writing a general purpose API. Then, based on testing, optimize where needed by creating additional API functions to address specific performance issues.

3. It is important to minimize actions that make too many API calls per user interaction. For example, modem communication takes roughly 1/10th of a second for the message to get from the client to the server and vice versa. You control this by creating an API that bundles multiple requests into one request.

4. Take advantage of object-oriented programming on the client side. This allows you to more readily change the look of the application while retaining the central logic. For example, it allowed us to go through several UI iterations without having to rewrite a lot of code. The Model-View-Controller architecture of the Pet Market allowed us to uncouple the user interface from the model, allowing multiple engineers to work in parallel on the client.

To fully understand how the Pet Market application works, you need to understand the following terms:

Timelines - Macromedia Flash MX has a main timeline and each movie clip symbol has its own timeline.

Main Stage vs. Library - You should understand that some of the data is on the main stage and some of it is in the library.

You should also understand the difference between movie clip instances and movie clip symbols—this is critical. Movie clip instances are individual instances of a movie clip symbol. For more information, refer to the Macromedia Flash MX documentation.

Macromedia Flash Remoting - Macromedia Flash Remoting is the gateway technology that connects Macromedia Flash MX components on the client side with server-side application services. Macromedia Flash Remoting enables Macromedia Flash MX SWFs to make use of web services.

Movie clip events - Describes how to make movie clips respond to clicks and presses.

CFML - ColdFusion Markup Language tags (CFML) are similar in syntax to HTML tags. But unlike HTML, CFML enables you to create dynamic web pages.

ColdFusion Component - ColdFusion components (CFCs) are files, written in CFML, that encapsulate application functionality and make that functionality available to a variety of clients, including web browsers, other ColdFusion developers, Macromedia Flash Player, and web services. When you create a ColdFusion component, you include the .cfc extension in the file name.

ColdFusion Page - A ColdFusion page is a text file containing ColdFusion Markup Language (CFML) tags, functions, and operators that is interpreted by ColdFusion MX. When you create a ColdFusion page, you include the .cfm extension in the file name.

Macromedia Flash MX: Better Interfaces for Web Applications (PDF 1.85MB)
Put your users first. Find out how Macromedia Flash MX interfaces make web experiences smoother.

Creating components in Macromedia Flash MX
This article explains how to create a component in Macromedia Flash MX, including defining parameters, adding a description, and creating a custom interface and a Live Preview.

Creating forms with UI components in Macromedia Flash MX
Learn how to create a simple order form using the Macromedia Flash MX UI components in Macromedia Flash MX, and how to submit the form data using the new LoadVars ActionScript object.

Getting Started with ColdFusion MX
New to ColdFusion? Hit the ground running with these tutorials and articles.

Creating CFCs and Web Services in Dreamweaver MX
An overview for using Dreamweaver MX to create, generate, and modify CFCs.

Jason Hatcher is an Instructional Media Development (IMD) Manager at Macromedia and a member of the Sitespring engineering team. He has written documentation for Sitespring, Macromedia Flash MX, and the Macromedia Pet Market blueprint application.