First, let us look at the catalyst workflow that’s been all the rage in the demos online that introduce catalyst (like this one).  Refer to the diagram below.

Pros:

• Super simple

Cons:

• Limited to one designer and one developer
• Limited to a single catalyst project
• Developer can’t start until designer is finished
• Once the designer has handed off the file, they can’t make edits.

If your software development process can handle those cons, this “super simple” option will rock for you.  But for anything beyond the most trivial of projects, those restrictions will be a deal breaker.  I consider this workflow similar to editing Actionscript in keyframes on the timeline in Flash.  It works, it’s simple, sometimes it might be the right way of doing things, but most of the time it’s like shooting yourself in the foot.

Something that hasn’t been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:

In this scenario, the developer creates a plain old Flash Builder project.  While he’s doing that, the designer creates a .FXPL file.  The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project.  (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst.  Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).

Optionally, the developer can move the classes into a package structure inside Flash Builder.  If there will be more than a single .fxpl imported, this is required since there will be name conflicts.  Currently, the refactor in Flash Builder doesn’t work 100% for this as the skin references aren’t updated, hopefully that’s just a beta-bug and will be fixed.

This is a huge improvement over the previous workflow and will probably work out great for most people.

Pros:

• Developer and Designer time can overlap
• You can have multiple designers and developers (by repeating that middle bit in the diagram
• Can use a package structure
• An “official” Adobe method

Cons:

• Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
• Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
  1. Delete the current Flex Library project
  2. Import the new .FXPL
  3. Modify the main project to reference this newly imported project
  4. Move the classes in the Flex Library project into a new package structure
  5. Rebuild the swc
  6. Rebuild the app
• Does not retain the Main class from catalyst, so all work must be done in sub-components

That’s doing a lot better in the scalability department.  It’s doing a bit worse in the complexity department.

What if we could automate some of the process of turning a .FXPL into a .swc?  Or even better, what if we could turn a .FXP into a .swc?  Then we’d have something that looks very similar to the previous workflow, but with one important difference:

Pros:

• Developer and Designer time can overlap
• You can have multiple designers and developers
• The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project.  (Coming Soon!  The next version of my script will)
• Automatically uses a package structure

Cons:

• Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
• Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
• Requires a script to run (requiring whatever environment that script was written in)

That may seem like a fairly minor difference, but imagine how much better it scales.

Instead of a single developer and a single designer, picture a whole team of them.  If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they’ll end up spending too much of their time just managing their build environment.  The more people you add, the worse it gets.

If that script can be run through a command line script, it can be automated.

Most teams that consisting of more than a couple people use a version control system.  That system can be used to distribute .swcs that are generated from the catalyst projects.  Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified.  If yours doesn’t have than a simple scheduled job could do it.  This can simplify the process even further to:

1. Designer checks .FXP into version control
2. Script runs, automatically generating the .swc
3. Developers sync up, getting the new .swc

That means, once it’s set up there is no additional work that needs to be done.  The designer works in his tool.  The developer works in his.  Assets are magically propogated.

If you don’t use a version control system, scheduled jobs and a shared network folder could do the same thing.

This solves the scalability problem.

All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It’s done. Go give it a try.

Blog post describing the script.
Download: fxp2swc.rb

Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?

1. Let me select a package that components get created in.
2. Export a swc with everything in it so we don’t have to go through most of this.

Last night I wrote a ruby script capable of doing exactly those two things.  I call it fxp2swc.rb.

Using the script is simple.  First open it up and set the two variables at the top.

The flex_dir just tells the script where your Flex SDK is. The default_package tells it what package you want your catalyst based components made in.

After you edit that, put the script in the same directory as your .fxp files. Run the script and you should see output like this:

$ ./fxp2swc.rb
=== FCTest.fxp
 Extracting to FCTest.fxp.tmp
 Creating directory FCTest.fxp.tmp/src/com
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying Main.mxml
 Copying FCTest.fxp.tmp/src/components/Background.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/CustomComponent1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginButton.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginForm.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/TextInput1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Removing old source locations
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Background.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/CustomComponent1.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginButton.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginForm.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Main.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/TextInput1.mxml
 Creating swcconfig.xml
 Invoking compc -load-config+=swcconfig.xml
Loading configuration file /Applications/Adobe Flash Builder Beta/sdks/4.0.0/frameworks/flex-config.xml
Loading configuration file /Users/mhughes/Dropbox/fxg2swc/swcconfig.xml
/Users/mhughes/Dropbox/fxp2swc/FCTest.swc (1463574 bytes)
Deleting temp dir
Done!

You now have a one .swc for every .fxp file! As easy as that!

Take the swc, and plop it into the “libs” folder of you Flash Builder project, and you can start using the components from it. They’ll be in a package that starts with your default_package variable and ends with the name of the .fxp you compiled. So for my example FCTest.fxp, the package is: com.roguedevelopment.catalyst.FCTest

Here’s a quick example of what it looks like to use one of those components:

You can still use the composition or inheritance methods of using those components that I blogged about the other day. Here’s an example showing that with view-source enabled.

I’m on OSX using Ruby v1.8.6 with this script. Your mileage may vary on other platforms. Two things that will likely need to change for Windows users:

• The compc call should use compc.exe
• It uses the unzip command line utility, not sure if that’s a standard tool on Windows