Section 14.1. The Component Framework

14.1. The Component Framework

The Macromedia Communication Component Framework (a.k.a. the Macromedia component framework, or simply, the framework) is a set of server-side files and coding rules that allows developers to build communication components , just like the ones that ship with FlashCom Server, which were described in detail in Chapter 2.

Before looking at the framework's code, it helps to understand why it was built and its general goals. During the beta period for the first release of FlashCom Server, the server was in a good enough shape to be usable; people on the beta program and inside Macromedia could start building real-world applications on top of it.

It quickly became apparent that, whereas the client-side code could be organized to follow old Flash patterns such as components and libraries or just simple movie clips, no such patterns existed on the server side. So FlashCom programmers would not be able to easily create a well-structured , complex application on the server side.

At the same time, during the development of all of the sample applications, we realized that we were building the same people list and chat components in every application, and it would make a lot of sense to encapsulate such common functionality inside client/server components, a new concept at the time.

To solve both of these problems, a couple of the smartest Macromedia engineers (Srinivas Manapragada and Jon Gay, backed by Sarah Allen) sat down in front of a whiteboard and designed the Macromedia component framework and wrote the code in about two weeks.

The framework's goals were multiple and sometimes diametrically opposed to one another:

Modularity

Using the framework, developers should be able to build complex, well-structured applications that follow the common object-oriented programming (OOP) patterns. The server-side code should be easily split into independent libraries.

Extensibility

Creating components on top of the framework should be easy. To meet this goal, each component's APIs should follow the regular Server-Side ActionScript APIs, such as onConnect( ) , onDisconnect( ) , onAppStart( ) , onAppStop( ) , and so on. The reasoning was that if someone were already able to write a server-side main.asc file, he should be able to write a component using the same APIs. In retrospect, this was probably a bad decision, because it made the framework's code much more complex and inaccessible to people who wanted to dive into it, which in turn caused some developers to distrust what the framework was doing (it's hard to trust code that you can't understand). Creating component-specific events and calling them onUserConnect , onUserDisconnect , and so on would probably have been easy enough for component developers to understand while shaving a lot of complexity off the component framework.

Multiple instances

One should be able to have multiple instances of a component in the same application, such as an application with two or more chat components. To make sure that the various instances would not conflict with one another, a naming scheme was devised so that each SharedObject or NetStream used by a component would be properly namespaced.

Seamless integration

The framework should be unobtrusive ; a developer should be able to code an application without using the framework, then add a communication component and load the framework on the server side (using load("components.asc"); ) without having her existing code break.

Authentication

A developer should be able to create an authenticating component. This goal was pulling in the opposite direction of seamless integration. If a component's onConnect( ) method can decide whether to accept or reject a client, how can we avoid conflicts with the onConnect( ) functionality in main.asc ? The compromise solution was to add onConnectAccept( ) and onConnectReject( ) methods to the application object, as discussed later.

Rich API

The framework should have enough APIs to make components easy to develop. Having a framework in place is one thing; having a framework that supports a rich set of commonly needed APIs enables developers to focus on their component's core functionality, rather than on how to fit within the framework.

Figure 14-1 shows the relationships among the core object model, the objects added by the component framework, and the communication components.

Figure 14-1. The FlashCom component architecture

It is important to note that even though developers build the components on top of the framework, they can continue to use the core objects such as Streams , SharedObjects , and others. The framework was designed to be as unobtrusive as possible; this allows you to include it in applications that don't have components. An application designer can add in as many or as few components as required, and they may be built-in, third-party, or other custom components.

The framework implements a lot of basic functionality on behalf of the components. We will discuss the framework's features in detail in the second half of this chapter. First, let's take a component apart to learn how it's built.