Mediator "handleNotification" switch statement alternative (Flex/As3)

[Sh0rtWave]

Hi!

I went to a Flex user's group meeting last night, and the topic was PureMVC. There happened to be a few PureMVC users besides myself there, and the topic of handleNotification/listNotification interests arose, and the switch statement that many seem to think is necessary.

The method I use arose because some of my mediators handle a truly obscene amount of messages (upwards of 40 in some cases), so I wanted a much better method of managing not just handleNotification, but also listNotificationInterests.

I stressed about it for a day or so, then came up with this:

In my ApplicationMediator, for instance, I have a method addMapComponent that I wish to trigger on a message ApplicationFacade.ADD_MAP_COMPONENT.

Thus, I define a map object like so

:

msgMethodMap = new Object();
msgMethodMap[ ApplicationFacade.ADD_MAP_COMPONENT ] = addMapComponent;

Next I have to worry about getting that notification interest back to the facade, so I then do:

:


override public function listNotificationInterests () : Array {
var interests:Array = new Array();
for (var key:String in msgMethodMap) {
interests.push(key);
}
return interests;
}

Now comes handleNotification. You can probably already guess where I'm going.

:


override public function handleNotification( message:INotification ) : void {
msgMethodMap[ message.getName() ]( message.getBody(), message.getType() );
}

That's it. One line of code.

For your individual handlers, you can either choose to use the type portion of the message, or ignore it...I personally like using it since I can then have an extra layer of message categorization that's separate from my data payload.

Note too, that this method would work in python as well.

[puremvc]

Pretty slick. A bit indirect and not for everyone, but in your case (heavy note traffic in one mediator) nice.

The reason for the switch idiom, BTW, is that it exerts a gentle pressure on you to keep the mediator simple.

Also, having so many notes to be handled tells me you've got a really fat mediator, and that's generally not such a good idea from a general OOP standpoint. Such a fat class usually indicates the need to refactor responsililities into other actors.

-=Cliff>

[Sh0rtWave]

I'm normally inclined to agree with that...but...circumstances currently dictate this. I'm working on getting reduced tho.

The app in question is a VMWare management app that has a TRULY obscene number of operations available through the webservice (750 registered operations). The WSDL for it is magnificent. My next step involves refactoring the hypervisor top-level data object into sub objects (propertyCollector, performanceManager, rootFolder, etc. semi-in-line with the server's own object model) but I'm still struggling with the best method of representing that. I keep going back and forth on the best way to represent server level objects, while keeping my client-side footprint as small as possible.

Thus, my mediator is a little overweight at the moment. I thought I would share the mapping technique, since it's a nice little way of keeping your interests and function handling in the same place (i.e. you only have to modify the one object, and voila, you get both things handled at once).

[puremvc]

I certainly see your point. Sometimes its like that. Usually it isn't, but it sounds like one I'd love to hear more about in an article when you've mastered it!

Cheers
-=Cliff>