Section 13.10. Summary

13.10. Summary

The components presented in this chapter all manage their own stream and shared object resources. For example, the PeopleList component's server-side code is responsible for creating and updating the people shared object. No other component updates it. The SharedText component's messages shared object is updated by the SharedText component's server-side object and is also directly updated by the client-side SharedText component's code. Updates may first occur on the server or in the client; in either case, the component manages its own resources. Separation of component resources is partly achieved by using a naming convention. All the component resource names and remote methods are grouped under a single name , pfcs , followed by the component's class name and then a unique name for the instance of the component. The naming convention was used for streams, shared objects, and remote method naming.

It is easy to look at components as small, self-contained applications. A component can maintain its own data, present it, and allow the user to update it. However, a component can also make its resources available to other components. The shared object of each component contains information about its current state and notifies any listeners of changes in that state through onSync( ) calls. For example, the PeopleList can present a view of the Status component's data within its listbox. As long as the PeopleList does not update the status shared object, both components can easily be modified and improved separately.

When you design a component, consider designing it so that the current state of the component is kept in a shared object. The information in the shared object should not include large amounts of data that are better managed by streams or a database but should be enough to maintain the component's state. For example, the TextChat component used streams to store messages but kept track of the streams it was working with and other information about the current chat session in a shared object.

Returning to the questions we asked before designing the SimplePeopleList component, let's consider them in a little more detail:

• Are any database, stream, or shared object resources already available to the component? In applications composed almost entirely of communication components, this question can be rephrased as, "What other communication components will be available in the application and what resources will they provide?" Consider, for example, whether a PeopleList or component like it can provide information about users to a component you are planning to build. Ask yourself if a component like the VideoConference component really needs to create a duplicate shared object of users or whether it can use the one from a PeopleList or PeopleGrid? Of course, exceptional circumstances may sometimes require a separate shared object.

• What resources must the component create and manage by itself? This is always the most important question. Don't try to manage too much with one component. Just manage the resources the component needs to get its job done. The TextChat should manage only text messages. The VideoWindow should manage only the stream it is publishing and the shared object that describes the contents of the stream. If a component must do more, consider having it broadcast a message to another component that implements it. For example, suppose you want to allow application-level commands to be issued from within a TextChat. If you want a user to be able to log out by typing /logout , have the TextChat component broadcast the message and have another component handle the logout event.

• What user interface components should the component contain? The primary user interface elements should be the primary view of the resources the component manages. However, you may need to have multiple views of data that belongs to one component. We've already seen an example in which the status of each user appears in both the Status component and the PeopleGrid or PeopleList. When you must provide more than one view of a component's data, consider creating a separate objectsuch as the column object and its CellRenderer created by the Status componentto provide the view. In other cases, consider creating an entirely separate component with no data of its own solely to display another component's data in a different way. Resist the temptation to hardcode the presentation of one component into another component that also is responsible for managing its own data. For example, if the PeopleList and Status components are ever refactored or enhanced, having the PeopleList include code that displays the user status could cause conflicts.

• What information must the component make available to other components or objects? Start by considering what the component puts in a shared object. Is the essential information there so that another component can react to changes in a meaningful way? Also, don't forget that, on the client, the v2 components can make use of an event broadcasting mechanism. For example, clicking the Questions icon in a PeopleGrid can send an event back to the Questions component to retrieve and display a user's questions.

Creating components is the first and perhaps most exciting step in creating full-fledged FlashCom applications. They provide a way to partition an application into manageable pieces that can be built and tested separately. And you can use many of the features of Flash and FlashCom to allow your communication components to communicate with one another in familiar ways, such as broadcasting events to one another and providing accessthough not controlto one another's shared objects. Building components frees you from worrying about the entire application and allows you to focus on building one part of it at a time. Once you get going with them, it is hard to stop. It is easy to create a long list of possible components and to keep adding features to existing components.