I was able to sneak into a two day Adobe Flex 3 training session a few weeks ago, and now I've finally had a chance to write down what my impressions are of the language and environment. This is Part 1 in a 3 part series on Flex. Today covers the Flex language, next up is the Flex Builder Eclipse Development Plugin, and last is the Flex Server and Adobe Integrated Runtime (AIR) components.
As a word of warning... these are opinions generated by a mere 16 hours in training. Errors and omissions should be expected (that's what the comments are for).
Flex is Adobe's platform for web applications. To the end user, the application produced looks like any other Flash application running in the browser. But the difference between the Flash and Flex development environments is large.
Unlike the Flash development environment (now called CS3), Flex has no concept of a movie, a stage, or a time line. This is good news for programmers because development no longer feels like it is taking place in an animators studio. Instead, Flex ships as an Eclipse based plugin. The IDE looks great: there is a nice looking UI builder, the Eclipse project wizards seem to work, the IntelliSense works good enough, and the debugger contains all the expected Eclipse options. The compiler is available for free, it is only the Eclipse plugin and the Flex server that requires a purchase
Flex applications are written in mxml, which is really just an xml file. The file contains xml based component definitions ("put text box here"), css to determine look and feel ("background is green", and ActionScript 3.0 to handle behavior ("MyTextBox.onClick(Event e)...").
For me mxml was a bit of a turn off because it mixed the xml, ActionScript, and css all in one file. Even with the syntax highlighting, there was a lot of noise to sort through when you wanted to get down to the business of editing ActionScript. It looked like all the naive sample Java Swing applications that Sun published (you know, where every sample is one big class that extends from JFrame). These examples influenced thousands of Java programmers, like myself, into thinking that every Swing app started with subclassing JFrame. Ack! Model, View, Controller anyone? I know this approach of mixing all three layers in one mxml file isn't required, and that css can be externalized to an application level css file. But it's sad to see Adobe implicitly promoting this style the same way Sun did with the Swing examples.
The good part of mxml is that it could drive component driver development. Each mxml file is typically a visual component that extends an existing widget and adds functionality to it. There are currently hundreds of existing components in the base component library, and more are available on the web for free and otherwise. All of the dependencies are located within the component, and the application is simply a shell that assembles these components into a coherent layout. Nice and reusable. Just like COM! Wait... that doesn't sound good. But it is like COM in that the goal is to define reusable components that developers can add to their component library. And it seems like Adobe wants to make it easier for 3rd parties to create and resell components, just like the COM business model. A ramification of this model is that 3rd parties become very important to the success of both Flex and COM. All the components look great today: crisp, well-animated, modern looking. But in 5 years they are going to look old, dated, and clunky. Everyone knows a VB 5 application when they see one; in 5 years will Flex apps be the same? The answer is maybe, depending on what happens with the community and what Adobe contributes.
Working with Widgets
Within the mxml file, Flex visual components are defined and laid out using xml markup. Verbose? Yes. Old Fashioned? Yes. Industry Standard? You betcha. The nice part is that layout and positioning are controlled within the component declaration. Compared with Swing's GridBagLayout, the Flex layout mechanisms were a joy. It was a lot of containers and alignment attributes, but it was all intuitive, especially for someone versed in JPanels and scarred by GridBags. What's more, there was an absolute layout option. Why did Java never include this with Swing? VB has always been easier to prototype with than Java, and my opinion is that the missing absolute layout manager has a lot to do with it. VB UI's were a breeze to throw together, and so are Flex's. The downside here is that resizing doesn't work. For a rich, pretty website designed by a graphic design professional, this might be a non-issue. But most pages I piece together benefit from resizing. As monitors grow in size, a blog column constrained to 600 pixels doesn't make sense.
But wait? Wasn't css part of the mxml? If you lay out the page in XML, then what does the css do? The answer: css only controls looks such as color and fonts, not the size and layout of the components. I love this because I've never graduated beyond html tables. Never once have I gotten css positioning to work. And now I don't have to!
Working with Data
One of the best parts of a dynamic language is the parsing and text processing capabilities. XML creating and parsing is a breeze with Flex. Look how easy it is to create a large XML document:
var employees:XML =
<name first="John" last="Doe"/>
<name first="Mary" last="Roe"/>
This is more intuitive to me than the equivalent Groovy Builder object that uses closures to build XML. Accessing XML is a snap too. Just take the XML object and reference it without the endless findChild(), findAttribute() method calls associated with Java parsing:
employees.employee.address.zip; // 98765
employees.employee.@ssn; // 789-789-7890
This whole thing makes me happy.
Flex components are tied to data sources, such as web services or files, using a very similar technique to Visual Basic's component bindings. A component itself has a data source attribute which references an ActionScript variable declared as Bindable. This is simple, slick, and makes for a great demo. However, a DAO layer would definitely be needed for large-scale projects. Remember, not only does the mxml file have AS, XML, and CSS in it, it now also contains bindings to the data model. Separation of concerns was not a design principle for the training material. Sure, it could all be separated out, but Adobe does not seem to be leading the way for higher quality Flex designs. One nice thing about this data binding is how simple the Ajax integration becomes. Since everything you need is within the mxml component, the component itself can connect and update itself asynchronously without crossing any layer boundaries. I was similarly impressed with Grails custom tags and the ease with which they could be Ajax-ified. The two aren't that dissimilar to someone without in depth knowledge (me).
The Bad Stuff
The other downside of Flex is the US$400 license you need to buy for the Eclipse development environment. While this isn't needed to develop Flex apps, it sure was nice. It's also the topic of the next part in this series.