GhostWire Component Architecture
This document outlines the GhostWire Component Architecture (GCA), the methodology behind it, and the advantages of using the architecture in FlashMX development.

The GCA is an easy-to-understand, yet flexible and powerful architecture used to separate the visual assets totally from the behavioral code in Flash components. The architecture allows us to build extensible, lightweight and truly skinnable components.

The following diagram gives an overview of the architecture:

A component using the GCA is composed from visuals and behaviors. The visuals are the normal movieclips we are all familiar with. The behaviors are actionscript classes inheriting from the GhostWire Base Class, which provides the basic functions to handle inheritance from multiple behaviors, snapping-to-pixels, etc.

The visuals provide the 'skin' of the component, while the behaviors provide the 'life and soul'.


Methodology
A typical development cycle is as follows:
(1) define the functional aspects (behaviors) of the component
(2) sketch the visuals and break them down into parts (movieclips)
(3) decide how the behaviors will manipulate the visuals
(4) code the behaviors
(5) create the visual asset(s) of the component
(6) group the visual assets into a movieclip
(7) drag-n-drop behaviors onto the movieclip
(8) package the composite into a component

The following shows the folder structure of GhostWire Components Set 3. As demonstrated, the codes (classes) and skins for the components are nicely packed away in their own folders. In most of the components, changing the skin only involves the swapping of a single movieclip in the component.



Advantages
Truly skinnable
As we can see from the above, the visuals and codes are totally separated from each other. In fact, steps 5 to 7 are really the 'testing stage' and step 8 is totally optional. Once we have developed the behaviors, they can be dragged-n-dropped onto any movieclips on the stage to provide them with the requisite functions/methods - the 'life and soul'. This allows us to create many different look-n-feel for the same behaviors, without affecting the codes.

Team productivity
In a team environment, the benefits of this become even more magnified. The visual artists and actionscript developers can work separately once step 3 has been done - whereby the naming conventions of the visual assets are specified and all parties adhere to these rules. They can work on separate files without worrying about confusing each other on file versions.

Visual design flexibility
The visual artists can create multiple skins without digging into layers of folders in the Library panel. They can work in the way they are familiar with, and without any fear of breaking actionscripts since they will not need to handle any. All the designers need to do is drag-n-drop the behaviors coded by the developers onto their movieclips. No longer would designers need to use complex skinning commands to create the look-n-feel of components - they just use the drawing tools they are familiar with and are therefore once again empowered with the flexibility they need to exercise their creativity (instead of being limited to what the scripted skinning commands can achieve).

Efficient code-reuse
This is clearly advantageous when you want different movieclips that behaves in a similar way, but look differently, within the same FlashMX application. Using the Macromedia FUIComponent architecture, this can get really messy (if not impossible). You would also not likely be able to reuse codes efficiently.

Because the GhostWire Base Class makes it possible for movieclips to inherit from multiple behaviors, we can attach as many, or as little, compatible behaviors to our movieclips as required. This paves the way for a mix-n-match system of creating components, and enhances code-reuse efficiency.

Easy updating
The GCA also makes updates easier. When there is a new version of the behaviors, all you need to do is delete the behavior(s) already attached to the movieclip, and drag-n-drop the new behavior(s) onto the target movieclip. Using a normal FUIComponent architecture, you would instead have to dig through the component folders and make changes within the nested movieclips, again.


Conclusion
Using the GCA, you can build flexible, lightweight and truly skinnable components. GhostWire Studios have developed several components based on this architecture and these components are available for purchase from this website.

The GCA is also suitable as a framework for FlashMX application development. As mentioned above, the architecture promotes team productivity, efficient code-reuse, easy updating and most importantly, empowers designers with the ability to create multiple skins for applications with ease.

For more information or assistance in adopting the GCA in your projects, please contact GhostWire Studios.