One of the few complaints I have about AS3 is how event management is closely tied to the display list. There are any number of circumstances where you’ll want application logic to listen for and react to changes (events) when none of the particpating members aren’t in the current display list, but handling this can be onerous with the standard event management schema.

A technique I use very commonly is to use a “static” Class to manage events that are dispatched or listened for outside of the current display list (I know, I know… there’s technically no such thing as a static class, but it’s not technically a Singleton either, or even an abstraction – so I’m calling it static for want of a better word).

A typical use might be for login/logout type operations, where several areas of your application need to react when a user logs in our out. When the user clicks a logout link, or logs in using an input and a URLLoader, you dispatch the event from the class itself (not an instance). In any of your other 25 classes that need to know the logged in status, you attach listeners to the class itself (again, directly from the class – not an instance). Similarly, you might use a CartManager class to detect and react to changes in the quantity and composition of line items in a shopping cart, so that the user could add X products, look around the site some more, remove some, view his cart, see how many items he had at all times, delete some, customize others, and all places that needed to show this were able to react appropriately, regardless if they were in the display list or not.

I started using this technique a couple years ago, and have since learned that’s SWFAddress uses the same idea – in fact the differences were just a few lines of code (I was extending EventDispatcher), but I found their approach a little more elegant so have modified mine to reflect the setup they used.