Exclusive Review: Macromedia brings Flash to the enterprise

After a decade of web-style development, I’m sold on the idea of using markup languages to describe the layouts of user interfaces and to coordinate the event-driven code that interconnects widgets and binds them to data. The original expression of that model was HTML and JavaScript, but variations have flourished.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Macromedia Flex 1.0 Macromedia, macromedia.com Very Good  7.4 criteria score weight Ease-of-use 8 20% Flexibility 8 20% Integration 7 20% Administration 6 15% Documentation 7 15% Value 8 10% Cost: Sold on a per-CPU basis, in two-CPU increments, starting at $12,000 for a two-CPU license; maintenance runs for 12 months from time of purchase and includes product upgrades/updates and limited phone support. Platforms: Server OS: Windows, Linux, Solaris. App server: JRun, WebSphere, WebLogic, Tomcat; JVM: Sun 1.3.1 and 1.4x, IBM 1.3 and 1.4 (with WebSphere), JRockit 1.4 (with WebLogic); Client: Flash Player 7 Bottom Line: With Flex, Macromedia continues to move the widely deployed Flash player away from its roots as a boutique animation viewer and closer to the mainstream of enterprise development. Competition looms in the form of Microsoft's forthcoming Avalon, but Flex is here today, offering a cross-platform solution that works with existing Web infrastructure and skills. About our Reviews and Scoring Methodology

Mozilla-based applications have been using XUL (XML User Interface Language) for years. The Laszlo Presentation Server uses a description language called LZX. Now Microsoft has previewed XAML (Extensible Application Markup Language) for Longhorn.

Now comes MXML (Macromedia Flex Markup Language), the latest development in Macromedia’s ongoing quest to reposition the near-ubiquitous Flash player as a general-purpose presentation engine for rich Internet applications.

As with the Laszlo product we reviewed last fall, Macromedia’s Flex is a Java-based and XML-driven presentation server. You can deploy it to an existing J2EE server on Windows, Linux, or Solaris, or use the included JRun server. Nothing about Flex inherently requires a J2EE environment, however, and Macromedia is working on an implementation for .Net, too. But for the time being, it only supports Java app servers.

For this review, I used Windows Server 2003 and JRun. The Flex server compiles an MXML file that describes an application into an SWF (Shockwave Flash) file that renders in a Flash player. Because the newest player (Version 7) is required, I could only test Flex applications in Windows and Mac OS X browsers, but not in a Linux browser. The Linux version of the player just entered beta, however, and Macromedia expects to release it shortly after Flex debuts. That is, of course, a crucial part of Macromedia’s strategy to make Flash the kind of universal client that Java aimed — but has so far failed — to become.

The Flex strategy first began to crystallize two years ago when Macromedia rolled out the Flash 6 player, Flash MX development tools, and ColdFusion MX server. The possibilities were exciting, and the back-end environment was comfortably based on Java and Web services. But the client-side discipline was alien to the corporate programmer.

One obstacle was the ActionScript 1.0 language, which lacked the strong typing and formal class model that a Java programmer would expect. The solution to this problem arrived last fall when Flash MX 2004 introduced Flash Player 7 and support for ActionScript 2.0. Yet the Flash IDE was still built around the concept of making a movie, not coding an application. Flex presents a development model that will make immediate sense to an enterprise developer.

Look and Feel

With XML markup at its core, Flex is inherently IDE-friendly, and Macromedia has two IDE initiatives underway. One, code-named Brady, builds on Dreamweaver MX. The other, code-named Partridge, leverages Eclipse. But I’m a firm believer in the less-is-more principle, and I’m happy to report that I’ve been able to use Flex productively with no fancier tool than my trusty Emacs text editor. The widgets defined in the MXML tag language — panels, tree controls, data grids, and form elements — combine easily and predictably, using a simple and clean syntax. 

One of the innovations in Flash MX was a component approach to user-interface widgets. The core set included check boxes, radio buttons, and list boxes — things that Flash programmers formerly had to build by hand. Both Macromedia and third parties added more complex components: progress bars, trees, calendars, charts. All this was done in ActionScript, which was great news for programmers who wanted to extend and reuse these components.

But designers were left wishing for a more accessible technique, and Flex delivers it in the form of MXML components. These are just files that contain MXML markup and that combine basic widgets into reusable packages.

Designers will also appreciate the CSS support in MXML. Styles associated with user-interface elements enable powerful control over the look and feel of a Flex application. There’s a catch, however. Although the CSS language itself is familiar to Web developers, the Flex object model is quite different from that of the browser. For example, the syntax to put borders on elements worked as I expected, but the syntax to adjust border thickness and padding didn’t.

Binding to Data

A Flex application can bind to data either statically or dynamically, and both approaches are useful. The sample RSS reader Macromedia includes, for example, sources its categorized list of feeds from a static XML file, but uses the Flex HTTP Service to pull the feeds themselves. The HTTP Service is one of three dynamic ways to acquire data. The other two are server-side Java objects and Web services. Using the latter, I filled data grids and tree controls with data drawn from Web services both external and local to the Flex server. In the local case, the server’s built-in Axis toolkit can be used to offer WSDL access to server-side Java classes.

When a service returns XML data, whether from a SOAP call or a raw HTTP call, it’s presented to the Flex application as a code object that you can navigate using ActionScript’s dot notation. I found this convenient for simple XML structures but annoying for complex ones. In the complex cases, I wished for the XPath and XSLT (XSL Transformation) capabilities that I normally use elsewhere to search and transform XML data. According to Christophe Coenraets, senior technical evangelist at Macromedia, XPath support is “on the road map” for Flex. Meanwhile, the best strategy is to use server-side resources to morph XML data into simple and regular shapes that work most naturally with Flex’s data-bound widgets.

A week’s worth of noodling with Flex left me hungry for more. It would take more than a week, though, to master the ins and outs of the Flex object and event models. And those skills won’t transfer anywhere else. That’s true of the competition, too. RIA (rich Internet application) vendors tout standards — including XML, HTTP, SOAP, ECMAScript, and in Flex’s case, CSS — but each product is a proprietary combination of them.

If we’re going to have any kind of independent standard, it will have to emerge from real-world development and use of RIAs. Flex makes it easier than ever to take first steps in that direction. When you combine strategic bits of Flash UI with conventional Web applications, for example, Flex cleverly smoothes out a classic Flash/browser integration hassle. Its History Manager enables users to undo changes in the state of a Flash application using the browser’s Back button.

Nice touches such as these make Flex a good choice for a gradual transition to richer, better-behaved Internet applications.