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: Mediator names and retrieval  (Read 10656 times)
graphex
Newbie
*
Posts: 6


View Profile Email
« on: July 22, 2007, 04:29:17 »

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
« Last Edit: July 22, 2007, 04:40:15 by graphex » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 23, 2007, 06:47:22 »

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>
Logged
m.bergens
Newbie
*
Posts: 6


View Profile Email
« Reply #2 on: October 25, 2007, 01:19:54 »

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:

:
        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...
« Last Edit: October 25, 2007, 01:26:32 by m.bergens » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 26, 2007, 10:21:07 »

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>
Logged
m.bergens
Newbie
*
Posts: 6


View Profile Email
« Reply #4 on: October 26, 2007, 10:43:14 »

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?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: October 26, 2007, 12:54:13 »

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>
Logged
Pages: [1]
Print