Register Mediator

[saulo.brust]

Hey PureMVC Coders,

What's the best place to register a Mediator? In a Command, facade method, in the View Component or other place?

I don't see a reason to create a command just register a mediator. I prefer to register in the View Component, at creationComplete handler. I guess it is more simple and straight to the point!

I'm doing this, inside the View Component:

private function init():void
{
   facade.registerMediator( new UserAddMediator(this) );
}

Is it right?

Thanks,
Saulo

[Tekool]

No it is not ok because the PureMVC paradigm is that views must don't know their mediators. By doing this, your view knows its mediator. You better have to use the startup command as in the EmployeeAdmin Startup command ( http://puremvc.org/pages/demos/AS3/Demo_AS3_Flex_EmployeeAdmin/srcview/source/org/puremvc/as3/demos/flex/employeeadmin/controller/StartupCommand.as.html ). It's only one line of code and it's quite more logical.

[saulo.brust]

I understood the reason for must not register a Mediator at view component. This makes sense at PureMVC.

But, it's very strange create a command just to register a Mediator. I think we can create a command for register many Mediators.

In my case, I have 3 Proxys and 10 Mediators. The business logics I implement in 3 Commands.

Thanks for help!

[puremvc]

Usually we have a StartupCommand that registers the initially required Proxies and Mediators all in one place. That gets kicked off from ApplicationFacade.startup().

-=Cliff>

[Mirux]

Hello,

I just got started with PureMVC, I think it is great but I have some doubts.

I've got a MacroCommand which Execute two subcommands which are: SetupModelCommand & SetupViewCommand.

In SetupModelCommand I register the required proxies and in SetupViewCommand I register the required Mediators, BUT.

I have a mediator called: AppControlBarMediator, which I can't initialize here, because it is a Mediator of a component which is a child of a VIEW (viewComponent), which has not been created yet because it is another state of my application.

I have two states for my application: LoginView and MainView.

So I thought for a minute and the only logic solution I found to this is, create a Mediator for my MainView, and on the "creationComplete" event of this view, send a notification to the MainViewMediator, in WHICH, I'd register the Mediator for the AppControlBar.

My doubt is, is there any "better practice" for where to register mediators or proxies? I read proxies can be retrieved from Mediators and Commands, but it is more proper to register them in the command.

I'd like to hear some opinions about this. I like following conventions and keep the code in order, so that's why I stumble on these silly details.

Shall Mediators be registered anywhere or is there an order? Is it recommended to unregister Mediators or Proxies if I am not going to use them anymore? I know it sounds logical but I'd like to hear opinions.

[Jason MacDonald]

If I understand your structure correctly, you have an AppControlBar that is a child component of another that has some kind of deferred instantiation, right? If this is the case, then why not just have the parent components mediator create and register the child [AppControlBar] mediator if/when the component  becomes avalaible?

It's quite appropriate to have mediators register other mediators for child components. See the Hello Flash demo for an nice simple example of mediators registering other mediators for children.

[Mirux]

Good, that's what I wanted to hear, either a confirmation of what I was thinking or a different view.

I thought that was the most logical way to do it:

It's quite appropriate to have mediators register other meditros for it's components children

I just wasn't sure if mediators registering other mediators was proper or okay with the puremvc paradigma/conventions.

[puremvc]

Yes this is fine. Often times the only mediator registered in the view preparation phase of startup will be the mediator for the application itself. Then the application mediator will, in its onRegister method, register the mediators for the application's top level mediated view components. Sometimes those view components will instantiate children at a later time. Usually it is the mediator of those view components that will register the mediators for their deferred children, by listening for their creation events.

Think about it this way, the mediator should be the only touchpoint in the application that 'knows' enough about a view component to wrap a mediator around one of its children. A command that would reach way down into the application to do this would be assuming too much knowledge about the structure of the app or view component, breaking its encapsulation and making it more difficult to refactor later.

Also see the Slacker AS3/Flex demo for more on the handling of deferred instantiation.

-=Cliff>

[Mirux]

Thank you Cliff.

[puremvc]

This is where deferred instantiation of view components puts a kink in the view prep. Have a look at the Slacker Flex demo (and read the article under News on this site that describes it). There is also a FAQ entry about deferred instantiation.

-=Cliff>