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: Philosophy: mediator storing display layers and creating mediators there  (Read 5694 times)
uncleunvoid
Full Member
***
Posts: 27


View Profile Email
« on: October 20, 2009, 06:44:54 »

Hello,
this is my first post here and I am fresh and ready to burn some rubber here (oeh).

I am re-writing my MVC framework from AS2 to 3 and am using puremvc as a base for it. Here is my first question towards the process:

I built a mediator that houses all main display containers for all application view elements. E.g. interfaceContainer for all the interface, messageContainer to stay on top of teh interface, displaying messages, etc.

a command is creating new mediators to put view elements into those main containers. My plan is to retrieve the container mediator and create my new mediator by giving him/her the container reference from my container mediator.

Does that sound like a sensible solution, or would I rather have the container mediator send a notification to a command, then creating the new view element, like a collection run of a notification to pick p all elements for the new mediator on the way?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 21, 2009, 07:04:46 »

I read this post several times, but I'm still slightly confused.

Are you planning to have more than one mediator holding a direct reference to a view component? This container mediator that holds all containers and then another mediator for each container?

Ideally you want only one mediator to handle a given view component.

But in a typical app, you might have an ApplicationMediator that has the reference to the main app, and then have it create the mediators for the direct children of the app in its onRegister method since it has a reference to them.

-=Cliff>
Logged
uncleunvoid
Full Member
***
Posts: 27


View Profile Email
« Reply #2 on: October 23, 2009, 08:20:34 »

no I just create a basic group of sprites that hold different application interface groups

e.g. interfaceSprite, systemMessagesSprite

those containers will hold quite a number of viewcomponents that are then represented by a mediator each, but the interfaceSprite, systemMessagesSprite i stored in a single general mediator

maybe they should go in a proxy, as there is not much that will happen to those sprites. they are just containers. But they will help keep the interface elements more clearly stacked
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 23, 2009, 08:48:55 »

Proxies shouldn't become involved in view activities, so you don't want to put them there.

So I suppose the question is how to get the new components into those containers. Don't retrieve the Mediator from a command and invoke a method on it if you can avoid it. Instead, create the component to be added, and send a notification that the container mediator is interested in. This will keep it loosely-coupled.

-=Cliff>
Logged
uncleunvoid
Full Member
***
Posts: 27


View Profile Email
« Reply #4 on: October 23, 2009, 09:27:53 »

yes i was thinking of something like this, like a step by step mediator creation, but I am not sure, if I would have the sorted out. maybe like this:

command(create new element)> noti: create new interface mediator(component)
mediator(create new interface mediator)> take the relevant layer, add component, noti: component ready(component)
command(component ready)> registers mediator according to component id(component)

does that sound quite right?
Logged
Pages: [1]
Print