What kind of events need to be handled by the Mediator?

[sasuke]

Hello everyone.

As far as my understanding goes, the mediator has the responsibility of mediating or orchestrating the components or the core actors of the PureMVC framework. So for e.g. if you would want to retrieve a piece of data from the database on your submit button, an event is dispatched from the button which is handled by the mediator which in turn:
- uses the cached proxy to make the webservice call OR
- fires off another notification which triggers or executes a command which in turn makes a webservice call

But is it logical to fire off local events to the mediator? By local events I mean events which don't need to interact with the PureMVC machinery and can complete on their own. For e.g. if on the click of a radio button I want to do some set a view property[ a variable declared in the script tag of the MXML file] to the value of the radio button, should I fire off a custom event on the click of the radio button which would then be picked up by the mediator or can I just write a handler method in the script tag which does all the processing without going to the mediator? Is is required that *all* events which the view is interested in capturing need to be dispatched to the mediator?

TIA,
sasuke

[Jason MacDonald]

The mediator is only concerned with events that require it to perform some other request. It may be to get data from a proxy and set it on the component,  or to send a notification that accomplishes some other task (via a command or some other mediator listening for it). The rest of your views should send and recieve events as they normally would in any none "frameworked" app. You don't want to route everything through the mediator, only things that require some action to be performed by other PMVC actors (Proxy, Mediator and COmmands).

[sasuke]

The mediator is only concerned with events that require it to perform some other request. It may be to get data from a proxy and set it on the component,  or to send a notification that accomplishes some other task (via a command or some other mediator listening for it). The rest of your views should send and receive events as they normally would in any none "frameworked" app. You don't want to route everything through the mediator, only things that require some action to be performed by other PMVC actors (Proxy, Mediator and Commands).

Cool, that's what my impressions were; stuffing everything in the mediator would be kinda messy given the role which has been assigned to a mediator i.e. mediation. Thanks for confirmation.

BTW, just so that we have the technicalities cleared up, what reason do you think I should present if I'm giving a PureMVC session and someone ends up asking "Why aren't all the events directed to the mediator? What practical harm might come of it other than the normal 'it is not a job of the mediator'"?

One reason that I can think of is that, the more "view" specific code in the mediator, the more difficult it becomes to port the mediator if the view changes given the high dependence of the mediator on the view. Any other reasons you can come up with?

TIA,
sasuke

[puremvc]

Because it is still perfectly valid for components to communicate with each other via events.

-=Cliff>

[sasuke]

Because it is still perfectly valid for components to communicate with each other via events.

-=Cliff>

Cool, that gives me two reasons for not pushing all the events to the mediator. Thank you everyone for your kind contributions. :-)

[sasuke]

On a related note, I feel that this point deserves a special mention in the documentation which states:

The View primarily caches named references to Mediators. Mediator
code stewards View Components,  adding event listeners, sending
and receiving notifications to and from the rest of the system on
their behalf and directly manipulating their state. 
 
This separates the View definition from the logic that controls it.

This para might just give the users of PureMVC an impression that everything needs to go through the mediator. Just a thought...?