BF on CF

Macromedia Flex is a brand new server product, one that is poised to forever change the way we coders think about building rich and engaging user interfaces.

Yes, I did say "server." No, Flex does not compete with ColdFusion. Yes, Flex and ColdFusion are designed to work together.

Having now dispensed with the obligatory preliminaries, I'd like to present Macromedia Flex to the ColdFusion audience from a distinctly ColdFusion angle. And so this month I will:

• Explain exactly what Flex is, from a ColdFusion user's perspective.
• Discuss the ColdFusion/Flex relationship.

So, What Exactly Is Flex?
The best way to understand Flex is to think about how you build Web applications right now. If you are a ColdFusion developer (or a developer who uses ASP, JSP, PHP, and the like) you probably build applications comprised of lots of linked pages. These pages contain client code (at a minimum, HTML and JavaScript) as well as server-side code (CFML, SQL, and so forth). You probably try to separate content (or back-end data) from presentation (the front-end UI), but you still use both to create your application.

So, in the case of a ColdFusion page, a browser requests a CFML file, ColdFusion parses and processes the CFML in that file, and then returns client code to the browser. The browser renders the client code on the client, but it is ColdFusion on the server that embeds that client code in the page. Put differently, ColdFusion is a server that dynamically generates client-side code.

So why all this analysis? Simply put, Flex works in much the same way. Whereas ColdFusion (despite being somewhat client independent and agnostic) generates client-side HTML, Flex generates client-side Macromedia Flash SWF files. Perhaps that's a bit too simplistic, but the analogy is sound: ColdFusion uses plain text files containing CFML tags to render browser content, and Flex uses text files containing MXML tags to render Macromedia Flash content. Compare the flows of both processes in Figures 1 and 2.

But that is where the similarities end. Unlike ColdFusion, Flex and its language, MXML, do not provide tags for database integration, sending and receiving e-mail, connecting to LDAP servers, or creating Web services. Whereas ColdFusion is more of an all-purpose application development platform, Flex has a far more focused objective and a very specific goal. Flex is designed to facilitate the creation of rich and engaging presentation layers, letting developers create well designed and optimally architected n-tier applications that adhere to standards and best practices. With Flex, coders can take advantage of the ubiquitous Flash platform from a very code-centric starting point, but what Flex generates is still Flash content. In other words, Flex is all about presentation and user interaction, and that's it.

Flex is actually similar to ColdFusion in one other way. Flex, like ColdFusion, is a Java application. Flex is deployed on top of standard J2EE servers, such as Macromedia JRun, IBM WebSphere, and so forth, in much the same way that you deploy ColdFusion, but more on that soon.

All of the previous discussion means that Flex does not compete with ColdFusion; rather, Flex needs ColdFusion (or Java, or .NET, or something, anything, providing back-end integration). A Flex application needs a back end, and that back end can indeed be ColdFusion (as in Figure 2).

How do ColdFusion and Flex interact? The answer is that it depends. There are two distinct ways to go about using them together.

ColdFusion As a Flex Back End
So, Flex developers write MXML code to render user interfaces, and rely on external systems for any and all transactions, business logic, and back-end processing. How does Flex access these external systems? Flex provides tags that developers can use to:

• Invoke Web services
• Make HTTP requests
• Call remote Java objects

It is worth noting that Flex itself does not really invoke Web services or make HTTP calls or call remote Java objects; Flash does that (possibly via a server-side Flex proxy). Flex generates a complete Flash application - a SWF file that runs in Macromedia Flash player - that makes all the back-end calls.

At this point, ColdFusion/Flash integration becomes obvious, Flex calls ColdFusion pages via HTTP requests, or invokes ColdFusion components (CFCs) as Web services. You can use any ColdFusion code that you can invoke through HTTP or as a Web service within Flex applications. To do this, you don't even have to have ColdFusion installed on the same server as Flex, although that configuration works too.

In Figure 3, the flow works something like this:

1. A user requests a Flex MXML URL.
2. Flex generates a SWF, which it sends to the user.
3. The user's Flash player executes the SWF.
4. The SWF makes HTTP or Web service calls from the player and obtains data.
5. The Flex-generated SWF uses that data on the user's machine.

This type of integration delivers true n-tier applications, and is best suited for actual applications rather than embedded controls, for example.

This integration is also ideal for applications with multiple presentation layers. For example, if you needed a straight HTML version of your application in addition to the more engaging Flex version, you could simply provide multiple presentation interfaces to your back-end code. You would put your application logic, without any UI at all, in ColdFusion components; CFML pages would invoke the CFCs and render the HTML version of the application; and Flex MXML pages would render the Flash version of the application. The bonus is that both use the same back-end code.

ColdFusion-Generated Flex
Earlier I compared ColdFusion rendering client-side HTML to Flex rendering client-side Flash. But the integration just explained is not really the same. When ColdFusion renders client-side HTML, for example, the CFML pages programmatically render the HTML, perhaps even embedding dynamic data at the same time. This is quite different from the integration described in the "ColdFusion as a Flex Back End," section where ColdFusion does not generate client-side Flash, it simply provides data to Flash, generated by Flex.

Can you use ColdFusion to dynamically generate Flash apps in much the same way as it can HTML? Yes, you can, through the Flex JSP Tag Library interface. Flex comes with JSP tags that you can use inside of JSP pages. JSP tags are much like CFML tags, except that they are written in JSP instead of in CFML. With Flex JSP tags, developers programmatically embed Flex tags such as the Tree tags or the Grid tag in their JSP pages so that when a user requests a JSP URL, the generated page has Flash embedded within it.

How does this help ColdFusion developers? ColdFusion code can call JSP tags too. CFML has a tag named <CFIMPORT> that developers use to import or include JSP tags; once imported, developers can use these tags like any other ColdFusion tag.

To be able to do this, ColdFusion and Flex must be installed on the same J2EE server. While this installation process is not terribly difficult, it's a manual process. This obviously requires ColdFusion Enterprise, and will not work with a Standalone ColdFusion installation, since the Standalone ColdFusion installation does not expose a J2EE server that could run Flex.

Figure 4 shows the workflow:

1. A user requests a ColdFusion CFML URL.
2. ColdFusion imports the Flex JSP tags.
3. ColdFusion generates a page, which contains both HTML and a Flex-generated SWF, which it sends to the client.
4. The page displays in the user's browser; an embedded SWF executes in the user's Flash player.

This type of integration is best for dynamically generated content, such as a dynamically generated and populated tree control. This type of integration is less suitable for full-blown applications.

Where to Use Flex
ColdFusion developers can think of Flex as being a replacement or an extension for the parts of the application that they'd have written in HTML, JavaScript, DHTML, and so forth. But that does not mean that you should write every HTML application in Flex. In fact, while some applications are great potential Flex candidates, others are decidedly not.

Flex is not intended to be used to replace specific form controls. For example, if you have an HTML form and use a pop-up calendar, do not replace the calendar with Flex code. The cost, the overhead, the bandwidth usage - none of those factors would make Flex an efficient option. Using Flex for whole parts of a form probably does not make sense. However, if you have a complex multipart form with lots of screens, form controls, and dynamic elements, then yes, Flex could be a good candidate.

Applications involving raw reporting, data browsing, or working with large amounts of data - where the emphasis is less on the presentation and more on raw content - are also not Flex's sweet spot. While Flex provides controls, such as the data grid, that you can use within these applications, the overhead, performance, and amount of coding needed may not be a fit for Flex.

Flex is not designed to replace Flash. If you use Flash for complex animation or sophisticated design work, you'll still use Flash.

Where Flex shines is in rich presentation of information, with an emphasis on "rich." Dashboard type applications are perfect for Flex, as are innovative ways to display and interact with specific data, such as shopping carts.

Of course, these are high-level generalizations, and there is no hard-and-fast rule here. The key is that Flex empowers developers to build rich and highly interactive user experiences. It is best suited for applications where this type of interaction is a requirement and where the project plan can accommodate the overhead associated with this type of experience.

In case I did not state this clearly enough, Flex does not replace Flash. In fact, almost anything that can be done in Flex can be done in Flash too; the major difference is the development model (including code management, the use of design patterns and best practices, team development, versioning and editioning, and more). As a Macromedia developer, you now have one more weapon in your arsenal.

Where to Go from Here
To learn more about Flex, and to obtain a copy of the Developer Edition, visit www.macromedia.com/software/flex/. Also visit www.macromedia.com/devnet/flex/ for articles, columns, and example applications (including ColdFusion-related content).

In addition to overviews, positioning, and technical content, you'll also find practical and honest discussions on Flex itself to help you determine if it is right for you and your projects. Macromedia wants to help you build a better user experience, and that may involve Flash, it may involve Flex, and it may involve both. Whatever it is, we'll help you get there.

Conclusion
Flex empowers code-oriented developers, allowing us to build rich and engaging user experiences using development models and principals that we can understand and relate to. Flex is new, and still evolving, but even now it can have a dramatic impact on your development, both what you develop, and how. Flex may be right for your project, and it may not, but either way it pays to have a basic understanding of what this new technology is, and of what it can do for you.