RShieldsLab

While trying to come up with a good way to document the methods and properties of my custom classes written to support projects at work I came across a few forum discussions of something called asdoc. "Hmm, built in to the flex sdk, in the bin folder... current project is AIR, not flex; oh, there's an aasdoc binary, too!" A few minutes later I had the following:

Not bad! Now my classes are all documented. Not well documented; I still need to go through them all and add asdoc-notation comments explaining what everything is and how to use it, but since I do my best to use coherent names the documentation shouldn't take much. Now instead of building documentation I can just properly code everything and the documentation will build itself.

Pretty simple command; the flex 3 sdk bin path is in my $PATH, so from the directory I want to publish to I call:

/Users/richard/Scripts/flash/AS3/Tribute/ is the home of my AIR project and /Users/richard/Scripts/flash/AS3/Tribute/src is my root source path, ie where my main mxml lives. It also happens to be where my main .as class lives, since pretty much all the mxml does is load a swf... Oh, by the way, what I'm working on will be an AIR application, so I'm calling aasdoc. If you're working on an actionscript api or a flex project or anything but an AIR app use asdoc, not aasdoc. Apparently aasdoc simply calls asdoc with a configuration setting for AIR so AIR classes don't generate errors. You can do a lot in AIR that can't be done in standard flash/flex...

More information on asdoc and aasdoc can be found on the Macrom-er, Adobe site here. There are also a few extra notes on how to use asdoc in interesting ways here. And the next release of the Flex SDK, Flex 4, looks like it's going to have an ant task to build the documentation automatically. Notes on that are here.

Thanks, Flex team. Now I can stop worrying about documentation and get back to making interesting things.