Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript

Web Topics
All Articles
Scripting Languages

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab

Colin Moock on Flash MX
Pages: 1, 2

Components and Movie Clips

Even for self-contained Flash development, MX offers some important breakthroughs for Flash authors. One of the big ones is the new Components palette -- ready-made UI elements that you can simply drag onto the stage, much like in VisualBasic. Components are possible because Macromedia fixed the separation between code and visual assets, which was an irritant in Flash 5. "While you had code-based objects and classes manipulating all your data, the problem was you had to associate code with a movie clip that actually flies around the screen," Moock explains. "The link between those two was always a bit of a pain, because movie clips themselves are represented by objects in ActionScript. You have object-oriented access to a movie clip but you have to maintain two hierarchies -- one of all the data in your movie and one of all your onscreen assets. So, a big change in 6 is that they let you hook movie clip classes into the regular class architecture. All you code can now go into one movieclip, and then you marry the two together.

"That's in fact what enables quite a lot of the components they're bringing out. Each of those is a movie clip class. If you imagine a VB environment, where you're bringing the listbox onto the screen and sizing it ... the way that's pulled off in Flash, each radio button or listbox that you're dragging onstage is an instance of a movie clip, and that movie clip is in fact a class that controls how that individual radio button operates. It was really difficult to build apps that are scalable and portable without the work they've done on improving the object model of movie clips. .... You need a rich API to control all these interface elements. The UI components that are built in really make that whole deal so much easier. There was a time when you would be building all your radio button classes by hand yourself, which might have been a month of the project."

Event Model

Event handling is another important area much improved in MX. The problem of "empty movie clip syndrome" -- where you created movie clips on the stage just to hold an event handler -- is a thing of the past. "You used to put event handlers directly onto objects at author time, so you would literally select your interface widget and you type into a text area, 'Here's my event handler.' So, you'd have all these event handlers sprinkled all over your movie," Moock explains. "Traditional developers really hated that sort of sloppiness. That was part of the quirkiness of Flash. They didn't understand, 'Why do I have to physically put something into this environment just so that I can capture a keystroke?'

"In MX you can assign event handlers remotely, using the normal JavaScript syntax. Now you can just say button.onPress equals this function."

ActionScript implements JavaScript's listener event model, so you don't need do click capturing on the stage at all. "Any object can be listening to a keypress by defining the keydown event and adding that object to the listener of the key or mouse object." Listeners can make the whole application more usable, Moock says. "In a lot of custom stuff, the developers don't bother adding tabbing order and accessibility and stuff like that."


While XML support is not new in MX, it (as well as string and array) was rewritten as a native C++ object. The result is that XML parsing is 50 to 500 times faster in Flash 6, and some tests are in the 800-to 1,000-times-faster range. You can now realistically load in, say, 300K of XML and expect it to be parsed without any problem. The faster XML also really helps multiuser apps. "Multiuser apps built in XML traditionally were pretty clunky because there was so much parsing going on -- 10 times a second it might be parsing out a 500 byte XML file, which adds up."

The Standards Problem

While Flash has certainly grown up, and may even become the preferred way of writing Internet clients, does Moock worry over the fact that so much content is going into a binary format controlled by a single corporation?

"I really used to have concerns about that. I come from a very standards-based SGML background. There are real problems. I had concerns even about accessibility," Moock says. Web browsers are way more accessible that Flash movies and even though Flash has made up some ground, it's still really not there. Until Flash 6, it didn't support international text, no unicode. I really love the Web because there's all this data up there and it's searchable and interchangeable and all those things the web is so great for.

"Sometime last year, I just decided the whole thing, even the existence of the Web itself, is an evolution. Basically Flash wouldn't be as popular as it is if it didn't fill some need and desire that the general population is creating. If we need to go through a single vendor's implementation of a platform that everybody wants, then we need to go through it. Eventually who knows, maybe it will die for the reasons everybody's worried about; on the other hand, maybe it won't. That really is just the natural development of the new medium.

"Flash is a loud message to everyone who is working on standards: this is obviously a need, so maybe it's time to pay attention to this kind of content. Maybe that's not possible in the context of a standards body. It's something that I've been emotional about on both sides and now I'm just agnostic because I'm interested to see how it develops."

Richard Koman is a freelancer writer and editor based in Sonoma County, California. He works on SiliconValleyWatcher, ZDNet blogs, and is a regular contributor to the O'Reilly Network.

Return to the Web Development DevCenter.