I've been an advocate of compiling from Catalyst to a swc in a two previous blog posts. (A Flash Catalyst / Builder workflow method , Compiling FXP->SWC, a Catalyst workflow) I'm hoping to explain why I prefer that workflow here. With big pretty pictures!
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.
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.
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:
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:
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.
Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?Share on Twitter Share on Facebook