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.

I have been thinking about innovation lately. Early on my career I was fortunate to work on a great team doing pioneering VoIP/PSTN work at a R&D lab for a major telco. This telco never did really capitalize on our project. Sure we got a patent or two, we did many demos where executives, industry analysts and community representatives were suitable impressed, but the lingering question we were asked was always the same: when can we have this? We never had a real answer.

Over the years since then once in awhile I see a feature finally implemented commercially (usually in the mobile phone arena) that we demonstrated years ago and while it feels validating of the work we did back then, it is also a reminder of missed opportunities. Now looking back it was interesting how even in a R&D environment most people were fixated with the traditional phone as “the UI” for communications.

The trend in VoIP was to literally take a picture of a phone and use it as the basis of your UI; the more photorealistic the phone, the more “advanced” the UI was perceived to be. It is funny since most people can’t really use most of the features of say their office phones. And it is no wonder, since most phones to use a highly technical phrase, “really suck”. To do something as common as conference calls together is an exercise in anti-intuitive frustration.

These days I am immersed in the Rich Internet Application world, trying to drag a major financial company into the Web 2.0 world. Unfortunately, the company is kicking and screaming. One of the problems is that for all the lip service paid to going with RIAs, using Flex, Web 2.0 commitment etc. etc. many of the people involved simply cannot conceive of breaking out the HTML, navigation and interaction by hyperlink, stateless request paradigm of traditional web apps.

Just like the old days, there are people that just cannot break free of the shackles of their preconceptions, crushed by the weight of the familiar not matter how inadequate it may be and how pressing the need to find something better. Because if you don’t, you can be sure a competitor will.

Trying to develop a real RIA in this kind of environment can become a self-fulfilling failure prophesy. The RIA is designed as a HTML-like application. The use of server push, FDS, even AMF becomes prohibited by the architectural overseers of the company. The slavish adherence to outdated legacy protocols, legacy servers, legacy groups in the organization cripples the performance. You cannot design a non-RIA-like RIA and magically reach all the benefits. Instead more probably you will run into the drawbacks for no real gain.

I have to wonder if you can really innovate in most large corporations. I think it is not just a matter of money and resources, even of corporate will, there has to be a corporate culture that it is capable of delivering when it matters. Unfortunately, I think many just cannot.

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… 

Is Savaje dead? I tried to access last week the Savaje developer wiki and forums, looking for updated developer tools. The developer sites seem to be down, although the company web site is still up. After doing some research on the web I found out that apparently it has closed its doors. I was one of many who jumped at the chance at and after the last Java One to get one of their developer edition Jasper S20 cell phones.

I found the device very capable and fun to develop for, even if the tools were a bit crude and buggy. It still is as far as I know the only phone to implement the JSR209, advanced graphics and UI for J2ME. JSR209 provides Swing support for J2ME and simplifies considerably the porting of Swing applications to J2ME, at least if your application can scale to the smaller screen, resolution and limited keyboard input. I ported a game I had done originally as a demo for the Nexaweb RIA Platform and it required only very minor modifications to get it running on the S20.

I think it is a shame; for all the relative success that J2ME has enjoyed in the cell phone market particularly with games, I think the fragmentation of the J2ME has hurt its adaptation as a computing platform and limited development to a lowest common denominator API subset (to some extent). And then you have the locked until crippled, nickel and dime mentality of many cell phone operators (and sometimes manufacturers) but that is a topic for another day.

It will be interesting to see what happens with Flash Lite. Will there be a Flex lite as well?

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.

This site will be a digital playground for ideas on software engineering, technology and life on a digital world. I intend to explore some of my interests and share knowledge and expertise on areas like Rich Internet Applications, Adobe Flex, Eclipse plugin and RCP development, mobile devices, etc. I will be posting demo applications, sample code, tutorials and open source tools on a regular basis. I hope the site will be enjoyable and useful for others that share a passion for software development.

This site works best under non-IE browsers, we suggest Firefox or Safari. Feedback is welcome, feel free to email me at ldl@luislejter.com or leave a comment in the blog.

Luis