Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Quick question about mediators  (Read 9542 times)
Mirux
Jr. Member
**
Posts: 11


View Profile Email
« 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?
Logged
dihardja
Jr. Member
**
Posts: 17


View Profile Email
« Reply #1 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.
Logged
Mirux
Jr. Member
**
Posts: 11


View Profile Email
« Reply #2 on: September 08, 2009, 07:02:14 »

Good, thanks. I thought about this all night, and that suits as a better solution.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 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>
Logged
Mirux
Jr. Member
**
Posts: 11


View Profile Email
« Reply #4 on: September 08, 2009, 01:10:15 »

I really like reading other people perspective about an issue. Thank you for your response Cliff.
Logged
Pages: [1]
Print