Publishers of technology books, eBooks, and videos for creative people

Home > Blogs > Adobe Flash Catalyst: Under the Hood - Part 5 The Transport

Adobe Flash Catalyst: Under the Hood - Part 5 The Transport

In the 5th and final part of this continuing series, guest authors James Polanco and Aaron Pedersen show how the integration of Flash Catalyst and Flash Builder is aided by a common file format.

James Polanco and Aaron Pedersen are the guiding geniuses behind the Web development firm, based in San Francisco. James and Aaron are working on a book for Adobe Press on integrating Adobe Flash Catalyst and Flash Builder 4 (both just released as public betas) into the Web designer/developer workflow. Throughout June, they've been posting a weekly series of items that takes a peek "under the hood" of these innovative tools.

Adobe Flash Catalyst: Under the Hood—Part 5 The Transport

By James Polanco and Aaron Pedersen

One of the main advantages of Flash Catalyst is its workflow integration with Flash Builder. Designers can start with a static design; add interactive features in Flash Catalyst; and then hand off their creation to developers for a direct import into Flash Builder. To make this possible Adobe has created a new file format called FXP. The format allows for Flash Catalyst projects to be created and consumed by Flash Builder via the commonly supported FXP extension. However, this file format is not as new as it seems and those familiar to Flex development will recognize it right away.

Before we crack open the FXP format and expose its true form, we need to first understand what Flash Catalyst is built on top of. To users familiar with Adobe Creative Suite applications and tools such as Illustrator, you will feel right at home with Catalyst. You’ll find a Layers panel, many of the same vector design tools, and even an animation timeline that will be familiar to Flash Professional, After Effects and Premiere users. However Catalyst is not built on the same engine as the Creative Suite products. Flash Catalyst actually shares the same engine as Flash Builder, which is built on top of Eclipse 3.4. Eclipse is an open source IDE (Integrated Development Environment) platform that is normally associated with hard-core developer tools that produce Java, Rails, and ActionScript code.

With this common platform, Flash Catalyst can leverage one of Flash Builder’s most powerful modules; the Code Model. The Code Model is what allows both tools to interpret the Flex project from a code structure standpoint and enables the tools to edit the Flex project code in real-time. For example, code hinting and code completion are examples of features that the Code Model provides to Flash Builder.

Returning to the FXP format, if we were to open an FXP file outside of Catalyst or Flash Builder, we discover it is nothing more than a compressed Flex project. Because of the Code Model and the Eclipse platform, Flash Catalyst can share a Flex project with Flash Builder and understand all of its inner workings. Once uncompressed the file structure of the project is almost identical to what developers have been working with since Flex Builder 2. To Flash Catalyst users it will seem familiar if you have checked out Code View and the Project Navigator panel.

Note: You can open an FXP file by renaming the file extension from .fxp to .zip and expanding it. On the Mac, you'll have to use StuffIt Expander, as the default compression tool provided in the Mac OS does not work for this purpose.

In the uncompressed directory you will find three top-level directories: html-template, libs, and src.

The html-template directory holds all the files necessary to create the HTML page to display our Flex project within a web browser. When you run your project in either program, the index.template.html will be copied, modified based on a set of preferences, and rendered as index.html in your default browser. Included in that file will be a link to all the history files produced by the history management features in Flex. Those files are located in the history subdirectory.

For those familiar with Flex 2 or 3 projects, you will notice something new. SWFObject.js (version 2.1) has replaced AC_OET.js as the JavaScript library used to detect and embed the compiled Flex project into index.html. For most users, this change will have little effect on their projects, but for those who want advanced JavaScript options this change will make a difference. See for more details on the SWFObject library.

When Flex libraries are linked to your Flex project, they are stored in your libs directory. These external files are bundled as .SWCs and contain compiled code very similar to a .SWF. The main difference between a SWF and a SWC is that a SWC cannot be run on its own, it must be linked into a SWF file at compile time. Flex libraries contain common code that can be leveraged within any Flex or Flash application. As of the public beta, Flex libraries are not available to users within Flash Catalyst, and their support in future releases is unknown at this time. There does seem to be another new file extension called FXPL that both products also support. In Flash Builder, a Flex Library Project can be exported as an FXPL file. Catalyst then has the ability (although it is not enabled in the Beta) to import the same file type. It is generally assumed that Flash Catalyst will soon be able to consume Library projects and leverage them in your Flash Catalyst projects. More than likely, at compile time the FXPL files will be come SWCs under the lib directory.

All of the source files that are created when you build your user interface in Flash Catalyst are stored in the src directory. Your application will contain a file named Main.mxml. This is the root of your application and will be the starting point of your project. Each component that you skin from your design assets will be contained in its own MXML file and stored in the components subdirectory of src. In our screenshot above we have included two components in our application and their skins are stored here. One is a data list and the other is the item render that is leveraged by the data list. Both files are linked inside Main.mxml.

When an FXP project is passed to Flash Builder, new files will be added as the logic of your application is constructed. Those source files will also be stored under src. Currently Flash Catalyst does not include the option to change where its files are stored, however Flash Builder allows developers to store them anywhere under src as they see fit. Because of this limitation developers should be consistent and store all skin classes created in Flash Builder under components.

As you can see, the file format is pretty straightforward. The most complex piece will be the src directory as your application grows. We hope that after looking inside the FXP format you have a better understanding of how similar Flash Catalyst and Flash Builder are to each other and how the common format helps bridge the gap between design and development.

Here are the other posts in this series:

Part 1: Introduction

Part 2: The Platform

Part 3: Design Integration Workflows

Part 4: Converting & Skinning Components