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: Proxy / Delegate - Configuration and Setup  (Read 7984 times)
toytonic
Newbie
*
Posts: 2


View Profile Email
« on: April 23, 2009, 02:42:31 »

Hi,

I've used PureMVC for a couple of projects now and I'm very happy with it. In my current project I have quite a few RemoteServices to handle and to mix together.

I read through some posts and decided to lay out the different service calls into delegates as different DataProxies will need to make use of them and even I want to reuse those delegates in different applications.

My question is now about a best practice how to setup/configure the proxies with the delegates?

I like to handle object configuration and object dependency layout in constructors. So currently I would go with something like this:

:
public class ConfigureProxiesCommand extends SimpleCommand {

override public function execute(notification:INotification):void {

var configProxy:ConfigProxy = facade.retrieveProxy(ConfigProxy.NAME) as ConfigProxy;

var delegate:SomeDelegate = new SomeDelegate(configProxy.gatewayUrl);

facade.registerProxy(new RemoteProxyA(delegate));
facade.registerProxy(new RemoteProxyB(delegate));
}
}

Since the config data is retrieved ansync via XML, I now have to locations/commands for my modelsetup: ModelPrepCommand and ConfigureProxiesCommand as I can setup my delegates as soon as config data is available. What I'm not really happy with.

Also I've never seen any example where a delegate was instantiated in a command.

Any suggestions on a different/better approach on this?

thanks,
chris
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: May 12, 2009, 05:19:19 »

As a best practice, you really want to move this activity out of the constructor and into onRegister. First, in MultiCore, it wouldn't work. You don't get your facade reference until initializeNotifier which comes after construction and before onRegister.

But more practically, anytime a mediators or proxy interacts with other actors via the facade, they should already be registered and able to take part in any conversations they start. For a Proxy, this means being retrievable, for mediators it means being retrievable and ready to receive notifications.

-=Cliff>

Logged
Pages: [1]
Print