Mediator names and retrieval

[graphex]

I'm wondering why the base constructor of proxy takes both NAME and data arguments, while the base constructor for mediator takes only a viewComponent argument, forcing the developer to override getMediatorName. Seems like it would be easier to do them both the same way.

I'm writing this because I just ran in to a case where retrieveMediator was returning null and it took me a bit to figure out why. Turns out I didn't override getMediatorName, thinking I was passing NAME in to the super call in my constructor.

Why is it arranged this way?

Now I know it is generally best to avoid referencing a mediator from elsewhere, but I'd rather spend time refactoring to avoid directly referencing a mediator than figuring out why I can't get the mediator's reference!

Sean

[puremvc]

Sean,

The use of getMediator, and in fact the need for a Mediator to have a name at all is really only owing to one rarely used situation.

There is the case when we want to have one Mediator instantiate another in a place other than its constuctor, as a result of the deferred instantiation of a viewComponent.

For instance, an application might have a TabNavigator with creationPolicy="auto", so only the first child is created at startup. When the user navigates to a new tab, the child is created. The app sends an Event which the ApplicationMediator  responds to by creating and registering the new Mediator. But this should happen only the first time. So before creating the new Mediator, it calls retrieveMediator to see if it exists yet. 

Otherwise, Mediators really don't need names except in as much as they help us in the debugger.

This and more will be shoing up in a FAQ soon.

As always, thanks for bringing it up and forcing a little light to be shed on the subject.

-=Cliff>

[m.bergens]

in this case, would it make sense to subclass the org.puremvc.patterns.mediator.Mediator into something like SingletonMediator which would always know its name to avoid this kind of boilerplate found in each concrete today's Mediator:

Code:

        override public function getMediatorName():String  {
            return EmployeeDetailMediator.NAME;
        }

or is there a need of this boilerplate code at all? In the debugger you can see a class name of an object...

[puremvc]

It is necessary because the mediator is automatically registered with the view, and this method is interrogated. It may not always return a constant value. See the HelloFlash demo for an example of a Mediator that returns something other than a constant since multiple instances are created.

-=Cliff>

[m.bergens]

I understand that. My question is, why not have a mediator class such as SingletonMediator subclassing v 1.6's Mediator which SingletonMediator  would work for the majority of the cases and know its name like, for example, proxies do; having the name getter with the name set by a constructor?

[puremvc]

You can certainly create such a class and use it in your applications. I plan to open a site soon that allows people to contribute useful add-on classes for use with the PureMVC framework.

However I don't want to add another class to the framework. There are plenty of places where another class could help to do this or that, but I'm shooting for keeping the framework itself as simple and small as possible.

-=Cliff>