99% of coding I do lately is built on top of the excellent PureMVC framework. Something that has been irking me for a while now is the way Mediators register and handle notifications dispatched from the View.
Part of working with PureMVC requires extending from the Mediator base class (more specifically implementing IMediator) as this contains two important methods, listNotificationInterests and handleNotification. Where this starts to get a little painful is you need to override both of those methods for every Mediator you create. That is where I came up with the idea of abstracting away these two methods by creating a ‘helper method’ which will map a notification to a handler. I should say that before doing this I searched on the PureMVC forums and found several people who have already encountered this issue and created their own implementations.
I’ve created my own extended version of the base Mediator class I’ve called AbstractMediator. This includes a custom method called registerNotificationHandler which you pass a notification name and call back method to. This is very similar to the addEventListener method used in AS3. Then you simply extend AbstractMediator instead of Mediator in your application. AbstractMediator automatically populates the array returned by listNotificationInterests and uses handleNotification to route incoming notifications to the mapped functions, thus you no longer need to explicitly override these.
Overall the main reason I wanted to create this was to significantly shorten the amount of code needed in each Mediator. *Cliff Hall, creator of PureMVC, has commented on this post below noting that once you account for separate functions to handle notifications it is not necessarily shorter than the default way of overriding listNotificationInterests and handleNotification.
This merely re-engineers the notification handling to use separate methods for handling notifications. I can’t see it ‘significantly shortening’ a concrete mediator.
The code in listNotificationInterests, (which generally just returns an array of literal strings) is now replaced by a series of calls (presumably invoked from the constructor) to registerMediatorInterests and is more complex because now you’re mapping those strings to handlers. You didn’t need to override a method, but the extra code making the calls, mapping the notifications to the handlers is going to net you the same amount of characters or more if you have more than one or two interests.
Next, the code in handleNotification is generally a switch statement with a case block for each notification. This single handler scheme was chosen because a) it is simpler, and b) it discourages doing anything terribly complex, which should be moved off into a command, since the mediator’s role is one of communication, not logic. By moving the handlers out of the switch statement and into handlers, you now have a) added the overhead of method signatures for all those new handlers, and b) encouraged doing more heavy lifting in the mediator, a step away from best practice use of the framework. Net code for this part of the ‘shortening’ is likely equal to or greater than had it been handled in handleNotification.
I would be interested to see a Mediator with 5 interests implemented both ways, to see this significant shortening.
-=Cliff>
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.