How would you pass references of Mediators between themselves?

[Karl Macklin]

Let's say I have a StageMediator, and a SomethingElseMediator

My StartupCommand registers both mediators:
facade.registerMediator(new StageMediator(stage));
facade.registerMediator(new SomethingElseMediator(stage));

My SomethingElseMediator has to use something from the StageMediator, so in the constructor of the SomethingElseMediator I define a stageMediator variable, and I get the actual object from the facade.retrieveMediator method.

However, let's say my StageMediator needs to ask the SomethingElseMediator for something.

The only way I can solve this is by creating a new method "registerMediators" in the StageMediator that retrieves any needed mediator, and then call that method at the end of the StartupCommand.

The result is, in my opinion, a bit cluttered and badly structured code. I'm curious if anyone has a thought on how to do it more neatly.

[Jason MacDonald]

You should be using notifications to accomplish this rather than having the Mediators talk directly. Have one mediator send a notification requesting something, the other listens for that note and responds to it by sending another note whcih the ornigial sender is listening for. Basically requires two notifications, one that each mediator is listening for and that the other sends.

You put the payload you want in the body of the notification.

[Karl Macklin]

That sounds reasonable... but still weird in a way.

Imagine you have the StageMediator, AnotherMediator and YetAnotherMediator.

StageMediator listens for notification RETRIEVE_STAGE and responds to that note with sending another note; SENDING_STAGE and includes the stage as the payload.

AnotherMediator listens sends the RETRIEVE_STAGE note and listens for the SENDING_STAGE note. When receiving the SENDING_STAGE note, the AnotherMediator sets does something with the stage, like set a variable with it.

YetAnotherMediator needs the stage as well, and uses the same approach. Now when the YetAnotherMediator sends the RETRIEVE_STAGE note, both YetAnotherMediator and the AnotherMediator reacts on that note. I can't (due to my lack of programming skills) think of a scenario where this would be problematic, but my instict tells me it could. Maybe I'm wrong. Do you know where I'm going with this?

[Jason MacDonald]

When mutiple mediators are listerning to the same notification, you can use the notifications Type property as a descriminator (if required).

[puremvc]

The stage mediator should be the only actor manipulating the stage. That's its job. It keeps the rest of the app from needing to know about it.

For instance, if you need to add something to the stage don't nave the stage mediator send the stage to another mediator to add the child to it. Instead send the object to the stagemediator to be added.

-=Cliff>

[Karl Macklin]

And I would send that object to the StageMediator using a notification, right? And not set up a method in the StageMediator that takes objects as arguments and adds to the stage?

[puremvc]

Correct. Send a notification (such as ADD_CHILD_COMPONENT)to the StageMediator with a DisplayObject as the body. The StageMediator responds to that particular note by casting the note body to DisplayObject and doing an addChild on the stage object.

You achieve the same end, but nothing has to depend on the stage mediator or know any methods it exposes. Since things are loosely coupled, it makes refactoring easier.

For instance, perhaps later you have a complex object on the stage and that's where you want things to go now instead of directly to the stage. So, you have StageMediator stop responding to ADD_CHILD_COMPONENT and now you have the ComplexThingyMediator take interest in ADD_CHILD_COMPONENT and add it to the ComplexThingy instead. The thing that emitted the object to begin with doesn't care where it ends up, it's done its job already.

-=Cliff>

[Karl Macklin]

Thanks for the great explanation.

This is a bit off-topic, but I don't want to start a whole thread for this question:

I'm making a card matching game as you know, and I will be posting it on kongregate.com. They have an API that allows the developer to submit statistics and highscores.
The way it works is that you instatiate a new KongregateAPI and then add that instance to the stage. Upon adding it to the stage, the API will automatically connect to their servers and be ready to send/retrieve statistics.

Initially I thought that of course this goes into a proxy, but how would I pass the stage to this proxy, or should I even? Basically what I have is a RemoteService Proxy-case that requires the stage to work. What would you do?

[puremvc]

Clearly their API hasn't been thought out with MVC in mind

Must their thing be added to the stage? If so, and if it encapsulates its own service communication, then don't try to wedge it into the PureMVC paradigm, you'll only make a mess.

Instead, just treat it like a view component that you were displaying high scores on the screen with. Wrap it in a KongregateMediator and also send a note with a reference to it to be added to the stage as discussed above. Finally, send notifications that the KongregateMediator hears and feeds it with.

-=Cliff>

[Karl Macklin]

Yeah that's what I did from the start.

Making my game has been a great learning experience with PureMVC, I've done so many things that breaks the recommended practices, but without breaking the rules I wouldn't have understood them so easily.

I read the recommended practices a few times before and I didn't grasp it completely. After using programming with it, and going back and reading it again, I understand most of it.

As I said I actually made a KongregateMediator from the start. And then I realized "wait, this is a remote service, why the heck am I making it a view component?". It was first after that I also realized it requires the stage to operate. So I kinda did the "most correct" thing by doing something wrong in the start.

What I'm saying is, thank you for a great framework! I'll let you know when the game is uploaded so you can compete for the highscore