Luis Lejter

The Cairngorm plugin has been rebranded the Flex Builder Enterprise plugin. (Alternatively the Enterprise plugin for Flex Builder, if Adobe does not like the former). The scope of the plugin really goes beyond Cairngorm and now aims to be “the tool” to complement Flex Builder for Flex Enterprise development.

On this note I am pleased to say I have implemented preliminary UML 2.1 support. Some of you had asked for UML capabilities and after some consideration I decided to go for it. The UML support implemented at this time consists of the following:

• Generate UML class model from project AS classes
• Generate AS classes from UML class model

The UML class model file format supported at this time is the .uml format used in the Model Development Tools (MDT) Eclipse project. As such it is compatible with the Graphical UML2 Editors part of the UML2 Tools sub-project that will be released in the Eclipse 3.3 (Europa) coming June Release (pre-release available in the Eclipse 3.3M6 build). It should be importable and exportable to other UML formats (like Rational) by using the Eclipse Modeling Framework (EMF).

I am sorry about the delayed beta, it is still coming and it is a free (and eventually open) beta. I will be taking some time off the day job to get this finally out the door. I do think this is an exciting tool, at least I am having fun developing it.

Hello Everybody,

First of all I want to thank all of you that have expressed support and interest for the plugin, specially for the patience :-). I had intended to release the plugin sooner. I still need to complete the plugin feature (for you not familiar with Eclipse features, they are used for branding and required for update-manager capable plugins). I also need to write release notes (there are some known issues and bugs).

Some of you have kindly offered to beta test the product. I am going to have a private beta starting this weekend, and hopefully by the end of next week depending on how many bugs pop up I will open the beta and make it public.

If you are interested in participating, please email me, the only requirement is to provide feedback in terms of bugs, problems or suggestions.

UPDATE TO THE UPDATE: I am preparing a public demo of the Plugin that will take place this Friday; the beta will start during the weekend, I need to get the demo out of the way first. Thanks to everybody that have expressed interest so far, I apologize if I have not been able to reply individually to everybody yet.

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…

This is the first post on a series about Extending Flex Builder by using the Extensibility APIs. This is not meant to be a primer on doing Eclipse plugin development, there are plenty of those out there.

Getting Started
What do you need to extend Flex builder and build your own plugin? Flex Builder itself contains all you need to write your own plugins. That is, the Flex Builder plugin + Eclipse flavor of Flex Builder. The stand alone one is based off a stripped down Eclipse where all non-Flex Builder functionality has been removed. All you need to do is to create a Plugin project, and add the dependency to the adobe plugins where Flex Builder extensibility APIs are implemented, ie. com.adobe.flexbuilder.codemodel.

Java
You may not have noticed but Flex Builder installs its own Java runtime inside of the Flex Builder Plugin install directory. It also configures Eclipse to use this runtime, which happens to be incidentally a Java 1.4 compliant runtime. With this in mind assuming you want your plugin to be usable by the majority of the installed flex builder user base without having to change the default settings (and potentially install a new Java runtime as well), it will need to be implemented using only the Java 1.4 APIs. This restriction can have implications to not just your own code, but also whatever third party Java libraries you may consider using from within your plugin.

Eclipse Extension Points
Adobe has chosen so far (to the best of my knowledge) to not publish any extension points for Flex Builder. Any third party plugin can only “extend” Flex Builder by using the public extensibility APIs. From a legal point of view the Flex Builder license prohibits explicitly “Reverse Engineering” so any APIs not published are presumably off limits (even though technically they will be accessible from your plugin code). UPDATE: Phil Costa, Adobe Flex PM has kindly provided some clarification on this point, please read the comments section for more information directly from the source :-).

Flex Builder Extensibility APIs
Adobe has chosen to expose and make public only a subset of the APIs they implemented for Flex Builder. The public APIs (called by Adobe the “Extensibility APIs”) expose primarily the AS3 and MXML code base of Flex and AS3 projects. These APIs are documented in Flex Builder under Help -> Help Contents -> Adobe Flex Builder 2 Extensibility.

The fact that only a subset of the Flex Builder APIs is public has an impact on the level of integration that your plugin can achieve with Flex Builder, particularly at the UI level. UPDATE: See comments section as described above.

Part 2 of this series will go into details of using the Flex Builder extensibility APIs.

The Cairngorm Plugin is an Adobe Flex Builder plugin designed to aid and simplify the development of enterprise software using Flex and the Cairngorm Framework. Some of its features include:

• Cairngorm end-to-end class generators for REST, Web Service (WSDL) and Remoting services.
• enhanced AS3 class wizard and AS3 code generator.
• custom wizards for Cairngorm specific classes.
• FlexUnit test and test suite generators.
• generates interactive Flex Cairngorm service test application and graphical FlexUnit test runner.
• ASDoc documentation generators.
• Cairngorm explorer view.
• e4x editor and expression builder.

The Cairngorm Plugin is currently undergoing testing and will be released very soon. In the meantime check the Cairngorm Preview Gallery page on this site for an in-depth first look at the plugin, including screenshots with detailed descriptions.

Feedback is welcome, feel free to leave a comment or email me at ldl@luislejter.com.