When to remove a Mediator for a view

[ajs35]

hi all,

i am new to MVC, only a few months experience... but i have worked with AS2 and AS3 for a long time.  i am used the PureMVC framework for the latest version of our product.  i have several nested views with a combination of components.  i am using "mode" and "view" changes to manage different form states and it works great right now to help manage and remove the child views... but when do i remove a mediator for a view?  is it hurting anything to allow a mediator to persist in the application if it only acts on notifications it is interested in?  seems like on register if i great a view for the first time, i can use notifciations to manage it's view state and to whether it has child views visible or not.  i hope that makes sense.  i have a dB driven application so all view components are built and managed by there mediator, so going with a fresh start seems like it might be excessive when managing what view is displayed.

thanks all!

[puremvc]

The mediator is typically a long-lived actor. If a view component is removed from the view hierarchy, you want to remove its mediator as well. But while the component is still part of the hierarchy, its mediator should still be in place. You don't want to register and remove the Mediator each time it is shown or hidden.

-=Cliff>

[ajs35]

thanks cliff... that is the answer that i was looking for.  i was unsure if removing a view managed by the mediator meant to remove the mediator as well... knowing it may still be interested in responding to notifications sent by throughout the life of the application.

what i have been doing is registering the mediators once when there first view is displayed.  then when it is needed again during the use of the application, the mediator can manage the adding/removal of the views it needs to display.

thanks for the response!!!

[sasuke]

Removing a mediator sometimes becomes necessary when you have views which share a set of common notifications which they listen to. Imagine a viewstack having two distinct views (view A & view B) which end up listening to a common notification from a proxy. If view A is not visible to the client, it makes little sense to keep its mediator alive and respond to notifications given out by proxies, commands etc.

Another option here would be to deactivate your mediator as soon as the view becomes inactive. For e.g. as soon as view A is swapped out of the viewstack to show view B, you can set the `active` flag of mediator A to false. Any notifications/events received get tested against this flag and action is taken only when the mediator has the active flag set to true. The problem I see with this approach is that there is a certain amount of boilerplate code involved when it comes to making this work (testing for liveness/activeness).

Maybe Cliff would be able to shed a bit more light on this one. Cliff?

-sasuke

[puremvc]

:

Imagine a viewstack having two distinct views (view A & view B) which end up listening to a common notification from a proxy. If view A is not visible to the client, it makes little sense to keep its mediator alive and respond to notifications given out by proxies, commands etc.If you have this situation, you just need to think through whether

1) Updating the hidden view actually causes a problem
2) If it doesn't, whether the update affects performance.

If #1 is true then, sure you need to handle this. You can easily have the mediator not respond to the note if the view component isn't shown.

As for #2 Unless there are hundreds of hidden views being notified, it's unlikely that you need to actually go the the length of removing the mediator until they're shown again (and then having to create and register the mediator again).

-=Cliff>

[sasuke]

You can easily have the mediator not respond to the note if the view component isn't shown.

How? By checking the 'visible' property of the viewComponent before handling a notification in handleNotification? How would the above scheme deal with UI components which utilize a timer to continuously send out events to the mediator?

[puremvc]

You can easily have the mediator not respond to the note if the view component isn't shown.

How? By checking the 'visible' property of the viewComponent before handling a notification in handleNotification?

Yes. Like:

:

        override public function handleNotification( note:INotification ):void
        {
            if ( ! rolePanel.visible ) return;

            switch ( note.getName() )
            {
                case ApplicationFacade.NEW_USER:
                    clearForm();
                    break;

                case ApplicationFacade.ADD_ROLE_RESULT:
                    rolePanel.userRoles = roleProxy.getUserRoles( rolePanel.user.username );
                    rolePanel.reset();
                    break;                   
            }
        }


How would the above scheme deal with UI components which utilize a timer to continuously send out events to the mediator?

This scheme is only concerned with turning away inbound notifications, it doesn't have any intersection at all with outbound events coming from the component. Those are handled in event handlers the mediator has placed on the component. But the same scheme can apply there as well:

:

        private function onRecurringEvent( event:Event ):void
        {
            if (! rolePanel.visible ) return;
            roleProxy.addRoleToUser( rolePanel.user, rolePanel.selectedRole );
        }
       

Basically you're just ignoring communications requests to or from the component when it is invisible. No biggie. If you need a more complex adaptation of mediator behavior to view component state, then you want to implement view states in the component. This is built into Flex but can be built manually in a Flash component. In any case you'd be looking at the currentState property of the component and moderating communications based on that state. This gives you more than the two states of visible/hidden.

-=Cliff>

[sasuke]

Just what I was thinking; thanks for the confirmation Cliff.