PureMVC Architects Lounge

Announcements and General Discussion => Architecture => Topic started by: Mirux on September 07, 2009, 03:35:10



Title: Quick question about mediators
Post by: Mirux on September 07, 2009, 03:35:10
Is it a good practice to register mediators only if they are needed?

For example, I have a notification two mediators are listening, BUT While I am on view1, I want the view1 mediator listen to this notification, and not the view2 mediator.

So I figured, instead of creating a notification for EACH view, I was wondering if I better register the mediator when I am gonna need it and then when I go out of the view, I unregister it.

Points of view about this, anyone?


Title: Re: Quick question about mediators
Post by: dihardja on September 08, 2009, 01:58:22
I would rather notify 2 different notification for that. I think it is more maintainable having different notification than managing which mediator should be removed and registered since you are dealing with 2 different mediators which are listening to the same notification.


Title: Re: Quick question about mediators
Post by: Mirux on September 08, 2009, 07:02:14
Good, thanks. I thought about this all night, and that suits as a better solution.


Title: Re: Quick question about mediators
Post by: puremvc on September 08, 2009, 10:28:03
Either strategy works:

A) Live Long and Mediate. Register mediators once and forget about them. Be calculating with the notifications you send, to take into account the mediator's constant presence. This is the path of least resistance, and what a slacker such as myself will choose every time if it doesn't cause a problem.

B) In and Out and Nobody Gets Hurt. Register the mediators only when they are needed, then remove them. This shortens the notification lists and can be an optimization point if you have a very chatty app internally. It also requires that you carefully manage and document the mediator's life cycle. I suggest using the StateMachine to control this sort of thing. So that mediators are created and removed at the change of state.

Obviously there are times when you want to terminate components and their mediators during runtime, and it's easy to have an event from the removed component trigger the mediator into self-removal.

But do you really need to destroy the login panel and its mediator when you're done with it? Or is it sufficient to just hide the panel, so the user never generates events that prod the mediator into action. Or a hidden report panel, that still gets spoonfed data from a proxy's notifications even if the user is on another view. Ok, it takes some cycles for binding to update the hidden panel.

That said, it's good to know what's going on in your apps and to know when you want to remove a component and its mediator from the picture and when just leaving it there but hidden causes no big issue. Development is iterative and this is often just an optimization that can be made once the app is actually working.

-=Cliff>


Title: Re: Quick question about mediators
Post by: Mirux on September 08, 2009, 01:10:15
I really like reading other people perspective about an issue. Thank you for your response Cliff.