PureMVC Architects Lounge

Announcements and General Discussion => Architecture => Topic started by: mittenimraum on October 12, 2007, 01:59:41



Title: Proxy Logic
Post by: mittenimraum 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



Title: Re: Proxy Logic
Post by: puremvc 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>


Title: Re: Proxy Logic
Post by: mittenimraum 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.