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 Logic  (Read 9109 times)
mittenimraum
Newbie
*
Posts: 2


View Profile Email
« on: October 12, 2007, 01:59:41 »

hi cliff,

i'm actually considering about your proxy principle in a case where
one proxy is dependent from another proxy. this could look like this:

public function FirstProxy( data:Object=null )
{
    super ( NAME, data );
}

public function SecondProxy( data:Object=null )
{
    super ( NAME, data );
   
   _firstProxy = FirstProxy( facade.retrieveProxy( FirstProxy.NAME ) );
}

is this a behaviour your have conceived in your framework or should two proxies communicate to each other through sending events to mediators? i think there could be cases where it is not mandatory the involve a mediator or execute a command. this would also mean that you have to register the proxies in correct order:

override public function execute( note:INotification ) : void   
{
    facade.registerProxy( new FirstProxy() );
    facade.registerProxy( new SecondProxy() );
}

i don't want to take care of the correct order in the applications startup command, so what do you think?


stephan

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 13, 2007, 07:25:50 »

You definitely don't want to have the Proxies rely upon Mediators for anything relating to the preparation of the Model at startup. The Model is prepped before the View, and therefore no Mediators would exist to answer a Proxy's Notifications at startup time.

There is no problem in having one Proxy create and register or even retrieve and work with another Proxy. This is often necessary.

For an example of one Proxy creating another, look at the CodePeek demo. You'll see an example in the CodePeekPrefsProxy which parses the XML database and creates the WindowMetricsProxy. In other apps a concrete XML Database Proxy often creates more than one Proxy from a single XML file, all done within its parseXMLDatabase method.

The problem is only when you create constructor dependencies between Proxies, as this forces a specific order for Proxy creation at startup.

To do what you suggest with fetching another Proxy by name and caching a  local reference to it:

:

public function SecondProxy( data:Object=null )
{
    super ( NAME, data );
   
   _firstProxy = FirstProxy( facade.retrieveProxy( FirstProxy.NAME ) );
}


You must make sure that you create your Proxies in order, or if the Proxy you're retrieving hasn't been created yet, you're not going to get a proper reference, and later access to it will fail.

If you don't want to worry about the order of Proxy creation, but you will still have inter-Proxy dependencies, don't eagerly fetch the reference in the constructor, but instead lazily fetch the reference in an an implicit getter.

Inside SecondProxy:
:

   private function get firstProxy():FirstProxy
   {
     if ( _firstProxy == null ) {
      _firstProxy = FirstProxy( facade.retrieveProxy( FirstProxy.NAME ) );
     }
     return _firstProxy;
   }
   
   private var _firstProxy:FirstProxy;


Now, your Proxy creation order shouldn't matter as you are not making Proxies depend on each other in their constructors.

Later when the Mediators are being created and are asking the Proxies for data, the SecondProxy will likely be called upon to do something that causes it to use its local reference to the FirstProxy. Inside SecondProxy's methods you should refer NOT to _firstProxy but INSTEAD to firstProxy, the getter, which will fetch and cache the reference on the first call, and return the cached reference thereafter.

Hope this helps,
-=Cliff>
Logged
mittenimraum
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: October 15, 2007, 02:24:21 »

i'll take a look at my code again, perhaps it is unnecessary
to fetch a reference in the constructor. thanks cliff.
Logged
Pages: [1]
Print