I’ve been looking at Adobe Flex. I think you may be interested.

As soon as someone says "Adobe" most people think "PDF". That’s just a part of their offering. And if one says "Flex" many people think "Flash". That leads to thoughts about glitz and animation and all of those things that are really wrong for business application software. Let’s fix some of those misconceptions.

Flex is software used for creating Rich Internet Applications – or RIAs. The focus of Flex is on things like text boxes, buttons, lists, etc – the sort of things that business software developers like. Flex happens to deploy in the Flash browser plugin. The Flash plugin happens to be used for both Flex RIAs and for Flash animations. With me so far?

Flash projects create SWF files. So do Flex projects. With Flash, you put images on a form, create a timeline to guide what the animations do at specific points in time, and use some code to manage events. With Flex, you drag/drop controls on a form, and use code to manage events like Click, Change, etc. If you’ve used just about any other GUI IDE like Visual Studio then you know how most Flex apps are created.

For both Flash and Flex, after making code changes you compile your project to an executable, which is contained in a SWF file. If you were using Java this would be a JAR, for .NET it’s an EXE or DLL, etc. To see the results of your effort, an HTML file uses an Object or Embed tag to define the SWF file – many developers use template HTML to deploy their SWF files and never even look at that code. Java would similarly deploy as an applet. For .NET to deploy in a browser, you need Silverlight – I’ll get to that in a bit.

So what does Flex look like?

Flex is a combination of XML and JavaScript, and very little more. You don’t even need to bother with the XML, it’s really just there as a convenience. Pretty much anything significant in Flex is done with script. The JavaScript that is used in Flex is called ActionScript. ActionScript follows the latest ECMAScript standards just like any other JavaScript but also includes features that are in the as-yet-unapproved spec for the next version of JavaScript – so you’re getting a stable but advanced version of what everyone else will be getting whenever the spec is approved. In addition to this, an extensive library of functionality is provided for ActionScript. Where JavaScript provides basic functions for Math, Dates, and String handling, ActionScript provides much much more.

What’s with the XML?

Developers like to create apps in a GUI IDE. Flex generally uses XML as the source for IDE code to render common controls. So when the IDE sees <mx:Label text="Hello"> or <mx:Button label="Submit">, it draws a label or button. The XML syntax with Flex-specific identifiers is called MXML (think Macromedia who came up with this stuff in the first place and Adobe then acquired them). When code is compiled, the MXML is transparently turned into script code anyway. Since it’s easier to do some things in XML, or more readable anyway, Flex developers will define visual aspects of their UI with MXML but add functions in ActionScript to do the real work. Some functions simply can’t be done in XML so learning the script is required.

What confused me when I first started to look into Flex was how the MXML and ActionScript relate. XML isn’t code so how does that work? And I don’t see anyone creating XML controls in application code, so how does code "control" XML? Remember that the XML is translated to code at compile time, so the button XML above would compile down to something like:

var btn1:Button = new Button();
btn1.label = "Submit";

So application code doesn’t manipulate XML for the UI at all. The XML disappears into code during the compile, so application code is working with objects exactly as if the application code itself had defined everything – and it can if you wish, but most Flex developers find the XML convenient for defining the GUI layout.

The GUI IDE I’m talking about is called FlexBuilder3. FB3 is essentially the Eclipse IDE (free and open source) with a ton of plugins to make the environment aware of Flex.

IDE? Free?

Uh, yes and no. Eclipse is free – and open source – as are many plugins created to allow various types of development with it. The Flex SDK libraries are actually free and open source as well. However, the FB3 IDE which brings together all of the tools is not free. It is offered by Adobe for the trivial sum of about US$300. Compare this to other products in the same area.

You can download the Flex SDK, write your XML and ActionScript in an editor of your choice, and compile and run the code entirely for free – but most people say the FB3 is worth the nominal cost.

Personally I find the FB3 IDE to be clunky, rarely helpful, missing some basic features, and otherwise a very amateur implementation of an IDE compared to most other development tools. IMHO it’s a good thing Adobe only charges $300 for it. If all you care about is render XML graphically and moving controls around rather than hand-code all of the UI details, then FB3 is probably worth the price. (I’m sure comments like this won’t win brownie points with Flex fans – oh well.)