Ted Patrick > { Events & Community } > Adobe Systems

There are many proven techniques for working with components. I am going to explore several of these techniques outside of the Flash world and attempt to show how they best apply to working with Flash components.

The first stop on this tour is into the world of COM, Microsoft’s component model. COM at a high level is a component interface standard. COM is a very simple idea, build a reusable unit of software (component) and add a versioned interface to allow it to be reused in a consistent manner from other software or within other components.

Here are some facts about COM:
Components can define many interfaces
Interfaces are versioned to provide consistent access to legacy software
Interfaces are a collection of methods, properties, and events
Components must publish a discovery interface called IUnknown

The amazing part is what COM doesn’t do, in that you can write components in any language and components internally can be structured without restriction. So long as 2 separate components implement a common versioned interface, they are assumed to be interchangeable and compatible. This is a huge advantage to the developer as you can interchange components without requiring code changes in the parent software.

So how does COM relate to Flash?

As I stated in the prior post, Flash components lack a defined interface. This affects Flash software in terms of component compatibility. Currently there is no way for me to switch between V1, GhostWire, V2, or Central components in a common code base as each presents different methods, properties, and events. This simple fact forces developers to embed component specifics deep into the software you are writing making upgrades difficult and overly cumbersome.

Another issue is that if we start embedding interfaces inside of Flash components, the components will get larger and unduly sophisticated. Interfaces are a programming metaphor that should work across components in a neutral manner. Embedding interfaces into components is a design mistake as it will only create problems when V3, V4, V5 are released or when core changes occur in F8, F9, F10 Flash Players.

One solution is for interfaces to be external from the component itself and use a driver to adapt to the specifics of the component in use. This allows you to control a component instance from an external object without coding to the components specifics. In PowerSDK FLOW, I call these external objects Controllers and Controllers contain interfaces for managing a component instance. Controllers import a driver containing the component interfaces and specifics on how to adapt to a particular type and version of component.

Here is some sample Controller ActionScript:

//create a Controller for a button components using driver ‘v1.mx.control.Button’
buController = new flow.Controller(‘v1.mx.control.Button’, _level0.myButton)

//use the button interface to set the label property
buController.button.label = “MyButton”

//use the button interface to move the button
buController.button.move(20,40)

//use the mc (MovieClip) interface to resize the button
buController.mc._width = 200
buController.mc._height = 200

The mc or MovieClip interface allows you to move and resize components without destroying their internal state. Say you adjust _width via the MovieClip interface, the component will be resized to fit the _width that is set.

Controllers can do much more that present a defined component interface. As they understand component internals, they can create/destroy instances and persist component data between instances. Next post I am going to cover Controller creation/destruction and persistence and potentially get into higher level objects like XUL. Looking at the material I need to cover there is probably 4-5 more posts, I have been working on FLOW quietly for quite a while. Stay tuned for more.

Comments and Questions are always welcome.

Cheers,

Ted ;)