Luis Lejter

A bit late perhaps but better than never :-). Continuing where we left off in part 1 of this series, the extensibility APIs of Flex Builder fall into 2 distinct parts: Code Model and Design Model.

Code Model: The Code Model APIs give access to the AS3 class and object model for a Flex or AS3 Flex Builder project. The Code Model will expose not only the classes you may have created yourself in your project source directory but also any classes defined in SWC libraries accessible from your project scope. It will also expose classes not defined programmatically but generated from MXML elements defined declaratively in MXML files.

The Code Model APIs are more geared toward obtaining information from your project code compared to providing the means to easily change the code model programmatically. However there are APIs to obtain information from the parse tree of an AS file including offsets that can be used to achieve code manipulation if necessary.

One thing to consider when using the Code Model APIs in my opinion is what kind of information do you need from your code model; some questions I suggest asking yourself are: How exhaustive is going to be to search and obtain the information? How often does it change? These questions will help decide if it makes sense to cache the code data and how and when to keep it up to date.

Let’s consider the Cairngorm Plugin as an example, and more specifically the Cairngorm Explorer View. The explorer view shows every class in the project that extends a Cairngorm framework class or implements a Cairngorm framework interface. It only shows those classes with source files in the source folder of the project (not from SWCs).

In order to find what classes from the project has a Cairngorm super class or interface we need to iterate through every class in the project, follow the inheritance chain for each all the way to the top if needed and check for a Cairngorm super class. We also need to iterate and check every interface implemented by our class and check if it is a Cairngorm interface. If we decide we want to cache this information and avoid searching for it repeatedly, how do we keep it up to date when a new Cairngorm class is created or an old class is removed?

My solution was to create 2 Singleton classes as information managers. The information managers had two objectives: the first one was to encapsulate the Code Model API functionality needed for the Cairngorm Plugin, and provide a simpler easier to use interface (The rationale behind this is that I thought the code model APIs while very complete and useful felt a bit low level at times).

The 2 information managers I created were the ASInfoManager and the CairngornmInfoManager classes. The ASInfoManager defines a simple API to obtain general AS code information for a given project. It does not cache any information. The CairngormInfoManager however provides information about Cairngorm specific classes and interfaces in the project, and caches the resulting information. It finds and keeps both the original Cairngorm classes and Interfaces defined in the framework itself and any subclasses or implementers defined in the project.

Note that since it is caching the information it has to be notified when the project code model changes. It also needs to notify any interested observer that is using the cached information. The first goal is achieved by implementing the IDefinitionListener code model interface, the second by creating and dispatching a CairngormChangeEvent that is ultimately used to notify the CairngormExplorer when a change has taken place.

Now I don’t want to simply parrot the information already available in the Flex Builder help, I strongly suggest to anyone interested in the subject to at least check out the introduction sections of the Adobe Flex Builder 2 Extensibility API reference.

To be continued…