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.

Get Programming Flash Communication Server now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.