flex and actionscript 3 with textmate and fcsh

Moving on to a new toolset to compile flex and actionscript on mac without flex builder. Fiddled around with XCode for a while. Then I decided that the compile times were too slow using mxmlc alone, and started using fcsh in the Terminal or iTerm. But that meant losing the convenience of compiling from within XCode.

Soooo, there’s TextMate, also a fine editor for the Mac challenged. And Joachim Van der Hoeven has put together a TextMate Bundle to compile mxml and actionscript 3 using fcsh (or mxmlc if you choose).

Installing the bundle is no problem, he gives you a script you can use to update the bundle on his site:

http://www.4d.be/update-as3-and-flex-bundle-script

The necessary ingredients:

• flex 2 sdk
• TextMate (39 euros well spent)
• the as3 and flex bundle
• iTerm
• fcsh

Each of these can be installed relatively simply, in other words: if I can do it, anyone can.

Things didn’t go smoothly right off the bat though. Some tweaks, or setup completion was necessary, at least the way things are set up chez moi.

First there seemed to be a problem with iTerm, so I got the latest version and re-installed that. Then I had to set the path to the flex sdk in TextMate, since by default the script looks for Flex Builder, which I decidedly don’t have, errh, don’t want to pay for. I also had to set the path for the -output parameter for mxmlc, since it’s at a different location than the project source files.

Setting these variables in TextMate is straight forward, once you figure out that it’s necessary. I needed to set these:

• $TM_FLEX_FILE_SPECS (the file to be compiled, same as -file-specs when you use mxmlc on the command line)
• $TM_FLEX_OUTPUT (the swf you get back, same as -output param for mxmlc)
• $TM_FLEX_PATH (the path to where you installed the flex 2 sdk)

In TextMate, I set the $TM_FLEX_PATH under Preferences > Shell Variables, since that’ll be the same for all flex/actionscript projects. Then I set the $TM_FLEX_FILE_SPECS and $TM_OUTPUT at the project level, since that can change with each project, and since for the current project I need the swf in a different location than the source files (and probably for most projects, anyway).

That’s a little hidden. With nothing selected in the project drawer, click on the little i at the bottom. You’ll get a box to enter any variables you want for the project.

So far so good.

The one last thing to fix is getting the browser to open up at the location I need it to. With the default -output location (same as source files) the compile script was opening up Safari to display the newly compiled swf. That was nice. But it seems to have broken now that I’ve changed the -output location. (

That’s for another time. For now I’ll make do switching to the browser and refreshing the page I need.

Many thanks to Christoph for his post that first put it all together for me. danke!

speed up flex compile times with flex compiler shell

If you’ve been playing with Flex sans Flex Builder, you may have experienced very slow compile times using mxmlc via command line. Very slow. Go get the Flex Compiler Shell, also known as fcsh. It speeds things up. A lot. Easy to get going: just copy the necessary files from the zip’s bin to the bin in your sdk location (it’s explained on the download page I linked to).

fcsh is the reason that Flex Builder compiles so much faster than using command line mxmlc.

Why is it so much faster? Here’s what the folks at Adobe Labs say:

One reason is that by keeping everything in memory, fcsh eliminates the overhead of launching the JVM and loading the compiler classes. Another reason is that compilation results (for example, type information) can be kept in memory for subsequent compilations.

This utility is intended to improve the experience of users of the command-line compilers. If you are using Flex Builder, you do not need to use fcsh. The Flex Builder tool already uses the optimizations provided by fcsh.

For simple applications, fcsh might not be necessary. But for more complex applications that you compile frequently, you should experience a significant performance improvement over using the mxmlc and compc command-line compilers.

Oh, and the application I’m working on doesn’t get much simpler. It might not be absolutely necessary, but the noticably faster compile times make flex play much, much more pleasant.

actionscript 3 and flex without flexbuilder on mac os x with trace()!

It was time to play with flex, but the price tag of flex builder was a little too high. And eclipse seemed too feature rich, a hurdle in itself, and a simple editor solution was more fitting for starting out. Fortunately others have done the work of getting their favorite editors to compile to the Flex SDK compiler (mxmlc, included in the free flex download).

Josh Buhler’s great description of how to get XCode and the Flex SDK set up on Mac OS X. So far so good. That was all I needed to get up and running, fumbling around with Flex.

Then I missed trace( ), the ActionScript developer’s best debugging friend. After looking around and around, I got the simple solution I needed in FlashTracer, a Firefox plug-in made by Alessandro Crugnola, aka Sephiroth. Simple plug-in installation. You need to install the debugger Flash player, which is located at [your flex sdk install location]/player/debug/Install Flash Player 9 UB.dmg. (It’s an older version, 9.0.28.0, but it’s what you need for outputing trace statements.)

I vaguely recall a way to get the trace output displayed using features of Mac OS itself somehow, but it’s been months since I heard how that works, and this works so, all is OK. Yes!

—-

PS

What I’d really like is a Mac version of FlashDevelop, my most very favorite ActionScript editor, recently updated for AS 3. But it’s Windows only, and running it in Parallels is a pain, because my brain just doesn’t switch quickly enough between Windows and Mac keyboard layout. Lazy me will have to dig into remapping the keyboard in Windows. Yuck.

fumbling through flex: components > datagrid > itemeditors > dataprovider > scope

Been taking a whack at a little Flex app, using the freebie flex 2 sdk, editing with xcode and textmate. Rather than going at it systematically, I decided to fumble through, just trying to make something I had in mind work. Learning by doing, or rather, learning by fumbling.

The rough idea starts with a text field that autocompletes based on data from an xml file. Found a component that does that, called AutoComplete, a little trouvaille made by adobe that’s based on the ComboBox control. So far so good. Then I found a modified version that displayed info from the same data (dataProvider in flexese) in a DataGrid control. Moving right along.

Then I decided to try making the editable fields of the DataGrid use flex components to do the editing, like NumericStepper and ComboBox. Here’s where the fumbling got more intense. It’s not too tough to integrate those controls into the DataGrid: the itemEditor attribute of the DataGridColumn is pretty straight forward. It took a little more digging to get to the attributes of the these drop-in editors though.

For example, say you want to set the NumberStepper’s maximum, or get the ComboBox to display values based on a dataProvider of its own. Then you need to write out the element itemEditor specifically, instead of using the itemEditor attribute of the DataGridColumn. Like here.

That worked fine for NumericStepper. Then on to the ComboBox and it’s dataProvider. Say you have an ArrayCollection called myComboBoxData in a script block somewhere outside the DataGrid, and you want to use it as the dataProvider for a ComboBox itemEditor.

Oops. Compiling that gives an error about not being able to access myComboBoxData… hmmm, smells like a scope issue, no? Sure enough. After a little hunting, I found out that the mx:Component tag defines a new scope in an MXML file, to quote directly from the livedocs. The solution is to use the outerDocument keyword, like this:

<mx:ComboBox dataProvider=”{outerDocument.myComboBoxData}” />

That did the trick.

In the end, I decided not to use the DataGrid after all, since it was becoming too complicated to dig down into the DataGrid and I only needed to edit one item at a time anyway. So instead of displaying several lines of data in a DataGrid, I use single components for one set of data only. The user gets one AutoComplete component to fill in, then whatever they select gets displayed in individual components for editing.

Most importantly, the user doesn’t have a list of several things that they don’t need to see. And the ComboBox still gets to have its own dataProvider, and I can still set maximum of the NumericStepper, like above. And conveniently for me, there’s no scope problem because there’s no mx:Component tag creating a new scope. Simple > complicated > simpler. Fumbling along.