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: How to best couple Mediators with their view components  (Read 8214 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« on: November 26, 2009, 06:15:17 »

I want to know how I should register Mediators and set their viewComponent.  I think there are a million ways to do this.  I just want one.

First of all, it is necessary for me to create the view instances dynamically after initial application start-up.  These view instances are not static to the application.  For example, depending on the account log-in, different panel views will be instantiated and shown on-screen to the user (not the same as pop-ups, but like pop-ups, they are dynamically created during run time).  I cannot change this specification.  Nor can I alter the decision to use PureMVC as the framework.

So now I want to know how on earth I should approach this problem in PureMVC.

I have decided to use commands to initialize these views--the command notifications to be dispatched based on the content of an account information proxy loaded after login.  But that's as far as I get before I am stuck.

What should these commands do?  Obviously instantiate a Mediator.  Should it instantiate the view component as well (the non-pureMVC .as class)?  That way I can pass the view component to its mediator's constructor when I initialize it.  But it seems strange to instantiate an .as component in a Command...  Furthermore, these Mediator classes are essentially singletons (ie there are not going to be two of the same panel view component on-screen ever) so should I really even allow them to accept a view component parameter in their constructor?

If that's the case, then should I instantiate the view component in the Mediator then?

I'm leaning toward the latter solution but would just like to double-check that there isn't a better way.

I think this problem is essentially the same one that occurs when dealing with PopUps (except that popups also require closing logic--which I don't have to worry about).  Surely there's a commonly accepted standard someone can point me to?

For what it's worth, I have read the best practices document (about 3 times in the past 2 months) and browsed the forums here but am still utterly overwhelmed by PureMVC.  What I really want is a slightly more concrete framework--which PureMVC self-admittedly is not.  So I hope I can get some suggestions here and/or concrete examples of how to make some common sense decisions about a PureMVC based framework.  Knowing this, if you can recommend any posts or communities, you will forever have my gratitude.

Thanks.
Patrick

ps I have a ton more questions but want to get a response to this one first...

edit: sorry for the split infinitive
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: November 27, 2009, 08:08:56 »

Create the component in the Mediator. Always try to reduce the number of classes that 'know' a view component to 1; the component's Mediator.

Usually the component exists in the hierarchy and a Mediator is later wrapped around it. Here you are simply creating it inside the Mediator, no big deal.

Your next issue is how the component makes its way into the main view hierarchy.

Lets say, for instance, that you are adding a mediated Panel to a custom component based on HBox. The HBox has a Mediator, and this newly registered Panel Mediator sends the Panel as the body of a notification called something like PANEL_CREATED. The HBox Mediator is interested and calls a method on the custom HBox passing in the note body cast to DisplayObject (so it doesn't need to know the actual object its handling). The custom HBox then adds the new Panel to itself with a call to addChild.

-=Cliff>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #2 on: November 29, 2009, 10:41:26 »

Thanks!  That's exactly the kind of answer I was hoping for!  And put that way it seems so obvious.

By the way the the Slacker demo mentioned in the FAQ was quite helpful.  I just got stuck because deferred instantiation was also not quite exactly the same as what I wanted to do above.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: November 30, 2009, 12:30:52 »

No problem, glad I could help. Sounds like you might be a little under the gun on this project, so feel free to drop in here any time with if something's bugging you and the docs haven't made it clear.

-=Cliff>
Logged
Pages: [1]
Print