PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: inconduit on January 06, 2011, 04:55:47

Title: mediator for notification processing. no view.
Post by: inconduit on January 06, 2011, 04:55:47
is it bad practice to use a Mediator purely for processing Notifications (and sending out new Notifications accordingly), where the Mediator has no view component?

the specific scenario that's given rise to this question:

DownloadProxy sends Notifications; complete, progress, error, cancelled, etc.  the app needs to react to these Notifications in various ways.

i could create separate Command classes to process each of these different Notifications, but that seems excessive.  instead, i'm thinking of creating a Mediator that is interested in all of those Notifications, processes them, and sends out reactive Notifications.  it keeps everything grouped in one spot and all of that behaviour is related so i don't see a need to modularize it all out into separate Commands.

anything wrong with this approach? 

Title: Re: mediator for notification processing. no view.
Post by: puremvc on January 12, 2011, 11:00:19
Firstly, there's no problem with mediators and commands throughout the app being interested in those notes that come directly from the Proxy.

Secondly, there's also no problem with having a mediator that listens to notes and sends out other notes.

The danger with that mediator is that it might get to doing more than a little storage and logic, things we usually avoid with a mediator. But the reason we avoid those things is that usually the mediator is tending a view component and the logic and storage end up being 'code behind' pushed into the mediator in order to 'keep the view component clean', which is an anti-pattern within the context of PureMVC.

Have a look at the StateMachine Utility[1]. It is nothing more than a mediator that keeps the current 'application state', listens for certain notifications (ACTION/CANCEL) and in turn sends out other notifications (entering, exiting, changed announcements). When you implement the StateMachine utility you envision the states of your app and what transitions are valid. If an action note comes in that isn't valid for triggering a transition from the current state, then no corresponding outgoing notes are sent. Otherwise, exiting and entering guard announcements are sent, giving other actors a chance to cancel the transition, and then a state-specific changed announcement is sent followed by a more generic CHANGED note. It does all this in a very lightweight manner, and the result is a really orderly notification system.


[1] StateMachine Utility http://trac.puremvc.org/Utility_AS3_StateMachine

Title: Re: mediator for notification processing. no view.
Post by: inconduit on January 17, 2011, 10:19:10
thanks cliff, allowing the mediator a bit more logic than usual when it's not tending a view component is the confirmation i was looking for.  instinctively it seemed legit but i couldn't formalize a justification, so thanks.