Custom Flex components: Providing default yet overridable behavior
A good component provides enough out-of-the-box capability that getting up and running with it is quick and easy. An even better component allows for the flexibility of overriding and/or customizing that default behavior. As it turns out, providing this flexibility in your components is quite easy. This article will explain how to do just that.
Since Flex uses an event based programming model, the addEventListener() method is one of the foundational aspects of Flex development. The fourth parameter of this method is priority. What this does is allow developers to “rank” their listeners and specify in which order they should be executed. Listeners are called in descending order, so a listener with a priority of 2 will be called before a listener with a priority of 1, which will be called before a 0 priority listener, etc. It should be noted, however, that listeners will not necessarily finish executing before the next one in the queue is called. The default priority is 0, as evidenced by addEventListener()’s signature:
addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
The priority argument is the key to providing default yet overridable/customizable behavior in your custom components. The basic approach, in a nutshell, is to have your component listen for its own events, but with a priority of -1 (or any negative number, really). By doing this, you let users of your component (other developers) listen for the events externally as normal, but also give them the option of preventing the event from ever reaching your default internal listeners. The Event class provides a stopImmediatePropagation() method that prevents the event from being dispatched to any listeners with a lower priority. So if you add a listener with the default priority of 0 (or any positive number) and call event.stopImmediatePropagation(), the event will never reach the default internal listener, since it has a negative priority.
Here is an example, with view source enabled. The project that necessitated figuring this stuff out will hopefully be going live early next week, so stay tuned.
Update: The project is live!
You can leave a response, or trackback from your own site.

Useful … and a nice example. Thanks
[...] flexmdi handles a lot of the mundane tasks of an MDI interface for you: minimizing, maximizing, closing, etc. However, we also realize that the out of the box behavior will not always fit your exact needs. Consequently, one of our biggest architectural goals (and challenges) was how to provide enough default behavior that getting up and running was lightning fast while still allowing the fine grained control a truly useful project provides. I described the basic method we used in a previous post, but wanted to give an example more specific to flexmdi now that its live. [...]