I wrote that blog post. I replied to Cliff's comment there but I'll copy it here also:

I see your point about it not necessarily being shorter once you account for the actual handler functions.

Part of my motivation for this was that I constantly find myself adding my notification constants to the listNotificationInterests method but forgetting to add a case to the switch statement in the handleNotification method. Not a big deal but having a single registration method feels more elegant and “cleaner” with a similar syntax as the addEventListener method. Also the mapped handler functions can have strongly typed parameters which cuts out the need to explicitly cast notification objects as often needed when using the switch statement method.

I see your point about promoting best practices by using a single handler, however I often found myself calling methods from within this switch statement. Not necessarily because I was doing anything complex, but because It felt more ‘natural’ to contain code in relevant functions like everything else in AS3. I did consider the method signature overhead which comes with this kind of mapping however I assumed it would be no worse than addEventListener (I may be wrong?).

You’ve definitely offered some food for thought and made me re-think the point of Mediators in the context of PureMVC.

Just wondering if I'm likely to encounter problems loading the multiple instances of the same module into my main application since each module's core needs a unique key, right? I figured I could somehow create a unique-random string for it's key (maybe based off the time?) when instantiated but this seems a little hacky.

My module is really a 'layout' which will be populated with content provided by XML when it's loaded into the shell so I want to re-use it multiple times.

This is a Flash CS4 app, not Flex.

I'm thinking of implementing the Pipes Utility into an Flash application (not Flex) I'm building for work. The application needs to be modular with each "page" being contained in it's own SWF. Each module will be unique to each other, one is a video player another an interactive map. Modules need to communicate with the shell and vice verca.

As each module is unique they generally each have a different API which the shell needs to communicate with. For example, the map module needs to respond to input passed down from the shell where as the video player only needs to alert the shell that it's finished playing or has been closed by the user.

Is this a good candidate for using the Pipes Utility? If a module is unloaded from the shell and a notification is attempted to be routed to it will an error occur or does it simply fail silently?

Any help/advice is appreciated 

I'm wondering what is the 'best practice' for handling value objects in an application, specifically where they should be stored.

In the past I have kept value objects inside a directory named vo under my model directory (model/vo/). This makes sense to me as VO's are used to transport data from the model to somewhere else in the application.

However I have a situation where I have one mediator which passes some 'view state' information as a VO to another mediator via a notification. Since this state data doesn't pass through the model tier should I create a separate vo directory under the view directory (view/vo/)? Or is it OK to simply continue using the currently structure of keeping all VO's in the model (model/vo/)?

I had already looked at StartupManager and to be honest I don't think it's for me.

Part of the reason I thought a BulkLoader proxy could be useful is that it is not necessarily limited to being a start up resource loader but could be called anytime while the app is running.

For example, I'm currently creating a site which has several 10x10 social media icons which get loaded into the footer. I consider these non start up critical items so these get loaded AFTER the navigation and start up content has loaded.

Also I like the idea of a single loading proxy which fires notifications into the system over something like StartupManager which requires creating several Proxy classes.

I imagine the proxy would expose methods like:

addGroupItem(groupName:String, itemPath:String, itemID:String);
loadGroup(groupName:String, completeNotification:String, progressNotification, failedNotification);

The proxy would handle the instantiation of BulkLoader instances and route it's events to the notifications in defined by the loadGroup method.

I'm just wondering if anyone has attempted to create a Proxy for BulkLoader?

I was thinking of creating one but thought I'd ask here first. Basically the proxy would allow a series of items to be loaded as a group and then fire off a notification when finished. The notification would carry the loaded assets as it's body.

Has anything like this already been created? What's everyone using for bulk loading of assets?