PureMVC Metatags helper for Mediators

[Avangel]

Hi,

PureMVC is a great framework for developing RIAs. But sometimes it can require some repetitive and "useless" code from business point of view.

In my opinion, the biggest flaw is with the mediator, its listNotificationInterest() and handleNotification() methods that are the same for all mediators. Especially handleNotification(), which must contain a dumb switch/case testing all notification names and map them to private handlers.

So I wrote a little mediator adapter, called "MetadataMediator" that you should extend instead of regular PureMVC mediator. It enables you to remove those functions from your mediator and replace them with custom metatags declared at the top of your class:

[ListenTo(name=NotificationName,handler=HandlingFunction)]

And that's all

But it has some drawbacks too, please see the MetadataMediator source code in the following demo:
http://prog.13.free.fr/metatags_demo/TestMetaData.html (right click -> Source code).

Your comments are welcome !

Avangel.

[Avangel]

Sorry, the source view seems to be badly generated.

Please find the source Zip attached to this post.

[puremvc]

As for the 'dumb' switch statement, this is planned simplicity. It keeps mediators from taking on more responsibility than they should. Search these forums for 'switch' and you'll see all the pros and cons outlined as this dead horse has been regularly flogged for ages. The est practices doc also explains this.

But PureMVC was built with the idea of being able to easily replace pretty much anything if you don't like the out of box implementation.

However, one caveat with your approach is that you now very tightly couple your app to Flex.

Imagine in 5 years that both Flex and Silverlight have come and gone and you need to migrate your app to the latest platform du jour. If your app has followed standard PureMVC conventions you'll probably have an easy job; reimplement boundary objects (view components and data objects) and straight migrate the PureMVC stuff in the middle, dealing with little more than the syntactic differences in the languages.

However if you've gone down a Flex-specific rabbit holes in your PureMVC apparatus you may also be faced with recoding lots of stuff.

Another benefit of adhering to convention is new developers who know PureMVC will understand your app right away and be able to dive right into it.

-=Cliff>

[Avangel]

Hi Cliff,

Thanks for your comments. I didn't see your arguments when thinking about this trick. I agree that the switch statement in the handleNotification() method is planned simplicity, it really is. It is just boring Another good point to the switch is that I usually use this place to cast the generic notification.getBody() object into the type expected by the handler, and make type verification as well. I think it's a good place to but this kind of repetitive code with little business value.

Regarding the "technology-proofing" principle of PureMVC, I understand it and agree as well. You're right that it is preferable to make it easy to change the technology easily, they are moving so fast.

So finally, maybe this trick could be useful for small, personal software when you want to make PureMVC use a little easier with Mediators -- and using Flex of course

Thanks again for your comments, they are enlightning

Avangel.

[Gilbi]

This is slightly off-topic... I like the switch statement. However, I wonder if it might be adding unnecessary overhead in certain situations? Lets say within each case you are casting the notification with a different variable...

ie:

:

case ApplicationFacade.DO_IT:
   var dataObj:DataObj = notification.getBody() as DataObj;
   myComponent.aChild.loadData(dataObj);
   myComponent2.aChild.loadData(dataObj);
   break;

If you have a whole bunch of these types of statements that define a different variable, then each time handleNotification gets invoked, a whole bunch of unnecessary variables are instantiated. (I can't remember where but I read that the AS interpreter will instantiate every var in a function even if the block never gets executed.)

Obviously the hit would be negligible, but it could add up.

[puremvc]

Yes, this is true, the AVM will initialize these vars even if their cases are not entered.

However, the advice I've given has been that once a mediator has more than about 5 or so cases in its handleNotification switch, it is an indicator that the mediator may be saddled with more responsibility than it should.

This could mean that the API that the view component is exposing is too fine grained or that the mediator is handling the children of the view component and that they should instead be handled by separate mediators.

The limitations of the switch statement as used in the handleNotification method exert a gentle pressure on us to keep our mediators and view components simple (and thus more reusable and maintainable), pushing us toward the appropriate granularity as our application grows.

-=Cliff>

[Neil Manuell]

I like the switch statement, and abstraction of this method leads to obviscation

if it gets too long, your mediator is overloaded, and i have used this as an indicator in the past.
also, for good practice, your case statements shouldn't contain much code, infact it is best if they refer to class methods, then you don't need local vars, you can cast and pass body and type as method arguments.

the listNotificationIntrests gives you an immediate rundown on framework dependencies too.

cheers:~)

[Joel Hooks]

infact it is best if they refer to class methods, then you don't need local vars, you can cast and pass body and type as method arguments.

I've been trying more and more to use the method extraction refactor on these statements, as well as creating lighter mediators without two page handleNotification methods

I'm looking forward to the next version of Flex Builder. The templates are gonna be a great timesaver.