A Conversation with James Ward, Part II

---

Frank Sommers: Would you give us an overview of what a Flex application looks like from a developer's perspective?

James Ward: The underlying language for all Flex applications is ActionScript 3. All the Flex components are written in that language. We used ActionScript 3 in order to make the Flex framework maintainable and extensible.

When you're creating a business application, however, you don't always want to use the lowest-level language available in a framework. In Flex, we created a higher-level language, MXML, an XML language that sits on top of ActionScript. Because MXML is a domain-specific language targeting the rapid development of Flex user interfaces, you can quickly become productive with MXML.

Suppose you wish to instantiate a DataGrid, which is basically a high-capacity table with the ability to sort data, re-arrange columns, and so on. In MXML, you can instantiate a data grid with a typical XML syntax, and then set properties on the data grid via the XML tags for the DataGrid component. The MXML syntax allows you to insert a very complex component into your application with a single line of code.

MXML's XML tags can have children, and it's through XML child elements that you can do layouts inside containers. For instance, Flex has a VBox component, which is a container that lays out its components vertically. You specify child elements of the VBox XML tag to put child components inside the box, and the box knows how to lay those components out. If you were laying components out horizontally, where each component is placed to the right or left of the previous component, you would add those components as child XML tags to an HBox instead.

When you write MXML and then run the Flex compiler, the compiler takes that XML and converts it to ActionScript. In a second compilation step, Flex compiles the ActionScript to bytecodes for the Flash VM. The XML-to-ActionScript part of the compilation is a form of code generation, where we take a high-level language and convert it to the more general-purpose ActionScript 3 code.

You can write all your application in MXML and not use any ActionScript, but often you will use mostly MXML with a little bit of ActionScript. You can include the ActionScript code in-line in the MXML, between Script tags, but you can create separate classes and combine the MXML with the ActionScript code.

In most of my applications, the layout code that deals with drawing and laying out stuff on the screen ends up being in MXML. When I need procedural logic, or perform some UI changes based on what the user clicked on, for instance, I use ActionScript for that. I find that division of functionality between MXML and ActionScript to lead to easily maintainable Flex applications.

Frank Sommers: Why did you choose an XML syntax for your high-level UI language?

James Ward: One of the reasons was that in the Web environment, most developers are used to using XML-like languages, such as HTML. That makes the learning curve very short: If you have knowledge laying things out in HTML, you can very quickly learn to lay things out in MXML. That has been born out in practice, too, and many UI frameworks have chosen XML for layout.

At the same time, the best way to think of MXML is as a domain-specific language for UIs. Someone could create another higher-level language to be used to generate the ActionScript code, and you could easily use the Flex compiler to generate the ActionScript code from such a language. One example that we've discussed on the Artima forums in the past is a Google Web Toolkit-like approach, where you write Java code, compile that down to ActionScript, and then compile that ActionsScript code into Flash VM bytecodes. That would be a very interesting thing to do, and I hope the community will take that idea up one day.

Frank Sommers: Could you walk us through the main steps of building a Flex application?

James Ward: As with most applications, you have to decide first if you're going to start from the back-end or from the front-end. You can have your Flex client communicate with any type of back-end.

If you develop a brand new application, you can start with developing the back-end. That's just like any enterprise application: You can use Java to model your domain objects, define your database, use an O/R framework, such as Hibernate or EJB 3. Then you'll want to create a business layer where you can query those objects and manipulate them, and expose that layer outside the application via HTTP. You can use Spring for that, for instance.

Although a Flex client can use direct socket connections, too, the most common way to communicate between a Flex client and a back-end service is through HTTP. HTTP communication is very easy with Flex, because we provide a simple HTTP client API with the HTTPService component.

HTTPService is an API on top of the Flash VM's HTTP connectivity that, in turn, uses the browser's HTTP library. HTTPService provides a higher-level abstraction for Flex developers to have a nice API to make HTTP requests. In most cases, the only thing you need to specify to an HTTPService are a URL and a call-back handler function. The callback function will be invoked when the HTTPService gets back a response.

The HTTPService supports REST-style HTTP URLs as well as SOAP URLs. If you organize your back-end API such that the action you want to perform come in as a parameter to a single URL, then you can just have one HTTPService for all those calls. With multiple URLs for the various requests to the server, you can easily set the URL value on one HTTPService. In larger applications, you typically write a singleton model locator object to access all your data objects.

You can tell the HTTPService how you want your response back: You can get back the raw server response, or you can have the HTTPService give you back XML, E4X objects, or even ActionScript objects. Of course, you can also get a JSON response back and deserialize the JSON objects into ActionScript objects.

Once you've defined how the client and server communicate, you would write some procedural logic next to invoke the services, retrieve some data, and put that data into some UI component, such as a data grid. Several Flex components, including the data grid, let you specify a data source. In Flex, you can define a data grid, an HTTPService, and have the results of the HTTP request serve as the data source to the grid, in just a few lines of code.

If you wanted to add logic to allow the user to edit some data, you can add event handlers to components, such as a handler to react to clicks, or a handler to be triggered when something changes in the data grid or in a combo box. When the user clicks on the "Save" button, you can add more logic there to validate data before sending the data back to the server. Flex provides several built-in validators for common data types, such as phone numbers, dates, or numbers. As with all Flex components, those validators can also be declared via MXML, and associated with components, such as text fields, for instance.

Flex also comes with a data binding framework. If you have data in one place, and you want that data to affect some other parts of a Flex application, you can bind the affected object's data model to a data binding source. We use curly-braces syntax for data binding that sets up a watch on the objects you're binding against. Whenever those objects change, the UI will change accordingly. If you have a data grid, and its data provider is bound to an ArrayCollection, which is a type of array that can serve as a data binding source, when that collection changes, the objects displayed in the data grid will also change.

Flex applications can take advantage of all the design patterns that have proven useful over the years in enterprise application development. Java developers may find a framework called Cairgorm especially useful. Cairgorm is available from the Adobe labs Web site, and it takes some of the core J2EE patterns and applies them to Flex applications. For example, Cairgorm provides commands and delegates, front-controllers, and the other enterprise client patterns that developers may already be familiar with.

Frank Sommers: What are the main tools of the trade for the Flex developer?

James Ward: The Flex SDK is available for free, including the entire Flex SDK source code, and it includes everything you need to develop Flex applications.

The main Flex IDE is FlexBuilder, which is an Adobe product based on Eclipse. It provides all the usual features of a top-notch IDE, including visual component layout, debugging, code editing, integration with version control, and many other features. One of the reason we built FlexBuilder on top of Eclipse was because we recognized that a lot of Java developers were using Eclipse. We decided to build the Flex IDE as a plug-in to Eclipse, and that worked out really well for us. With FlexBuilder, you can even debug your back-end Java and your front-end Flex code all in the same debugging environment, and hit breakpoints on both ends. That allows you to be very efficient.

There is also a thriving community around Flex. For unit testing, the two open-source projects are FlexUnit and ASUnit, which are very similar to JUnit. As for code coverage and style checking, I don't know of ActionScript projects yet. I'm hoping the community will find that they need those, and either take the existing tools and add an ActionScript dialect support, or create another version for ActionScript code.

I want to stress that Flex projects co-exist nicely with Java projects. For instance, I use Ant almost exclusively for my builds, and sometimes Maven, as both tools have great support for compiling Flex applications. On a large project, you really have to use those tools for your builds. We released several Ant tasks on the Adobe labs site that make it easy for you to compile your Flex applications. Of course, FlexBuilder has excellent build-support, too, and it will get you up and running very

Resources

Adobe's Flex SDK
http://www.adobe.com/products/flex/

An online Flex compiler
http://try.flex.org

Flex.org, the Flex community site
http://www.flex.org

A Flex component explorer
http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html

The ECMAScript4XML (E4X) Specification
http://www.ecma-international.org/publications/standards/Ecma-357.htm

The Mozilla ECMAScript 4 Proposal
http://www.mozilla.org/js/language/es4

Talk back!

Have an opinion? Readers have already posted 3 comments about this article. Why not add yours?

About the author

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.