Programming Flash Communication Server

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Components and Component Frameworks

|

661

components and component framework were driven by one overriding goal: adding

a component to an application had to be simple. All that is required to have a com-

ponent work is to drag an instance to the Stage in Flash, give it a name, and connect

it to a SimpleConnect component. In other words, little or no server-side coding is

required.

As a consequence, the server-side part of each component is automatically created

whenever a client-side component connects. For some applications, automatic gener-

ation of server-side objects (so-called lazy instantiation) is a great feature. But in

other applications, it represents a potential security problem. Another consequence

of Macromedia’s design choices is that all the server-side component class files are

loaded by the framework in case they are needed—whether they are used or not.

No authentication mechanism or hooks were provided with the component system

and little in the way of user management and control. See Chapter 14 for how to

authenticate users and Chapter 18 for some ways to implement role-based access

controls. And unfortunately, the namespace design of the components was not

extended to define a URI namespace for component resources. Component

resources are created in the root folder of the application instance, making it impos-

sible to protect other resources in subfolders using the

client.readAccess and

client.writeAccess properties.

Yet Another Component Framework?

Any developer faced with the need to create any but the simplest FlashCom applica-

tion has to decide whether to use Macromedia’s components and component frame-

work or strike out in a different direction. Chapter 13 presented a set of FlashCom

components that used little more than the v2 UI components provided with Flash. If

you read through Chapter 13, you will have seen a number of redundancies in some

of the components and other things that could have been improved. The remainder

of this chapter describes a very simple and lightweight component framework that

was designed as an outgrowth of the work shown in Chapter 13. Naturally, the com-

plete framework is available as a download from the book’s web site.

The design goals of this PFCS framework are:

• Remove redundancy from the Chapter 13 components and move common func-

tions into a base class (PFCSComponent) that can be used to develop new com-

ponent objects on the client and server.

• Provide a foundation for user authentication, user management, and better

server-side security on the client and server that is leveraged in later chapters of

the book.

• Keep it simple—add to the base classes and framework only features that are

needed to reduce redundancy and improve user management and security.