puremvc
|
|
« Reply #1 on: August 15, 2009, 07:19:42 » |
|
Once your Proxy is registered, then inside any Mediator, Command or Proxy in the same core, you can retrieve it and call methods on it.
Lets say you have a view component MyView which has three states: LIST_STATE, where the user can select a MyVO to view from a list, VIEW_STATE where the user can view the selected value object, and FAULT_STATE where any exceptions from the MyDataProxy are reported.
Lets also imagine that the full list of MyVOs might be quite large, not all in memory. So MyDataProxy exposes a getVOList method which fetches the list of available VOs and their names and IDs. It then sends this list as an XMLListCollection in a notification, used to populate a list in MyView.
Each XML item in the list has a label attribute to show in the list box and an id attribute containing the id of the actual MyVO to fetch if the user selects it. When the user selects an item in the list, the id attribute is exposed by MyView as a 'selectedID' property for the Mediator to inspect.
The implementation of MyView and MyDataProxy can mostly be inferred. MyViewMediator might look something like this:
override public function onRegister():void { myDataProxy = facade.retrieveProxy(MyDataProxy.NAME) as MyDataProxy; myDataProxy.getVOList(); myView.addEventListener( MyView.VO_SELECT, handleVOSelect ); }
override public function listNotificationInterests():Array { return [ MyDataProxy.VO_LIST_RETRIEVED, MyDataProxy.VO_RETRIEVED, MyDataProxy.FAULT ] }
override public function handleNotification( note:INotification ):void { switch ( note.getName() ) { case MyDataProxy.VO_LIST_RETRIEVED: myView.state = MyView.LIST_STATE; // could be encapsulated in MyView.voList setter myView.voList = note.getBody() as XMLListCollection; break;
case MyDataProxy.VO_RETRIEVED: myView.state = MyView.VIEW_STATE; // could be encapsulated in MyView.vo setter myView.vo = note.getBody() as MyVO; break;
case MyDataProxy.FAULT: myView.state = MyView.FAULT_STATE; // could be encapsulated in MyView.errorMessage setter myView.errorMessage = note.getBody() as String; break; } }
// Handle selection of VO from list private function handleVOSelect( event:Event ):void { myDataProxy.getVO( myView.selectedID ); }
// Cleanup private function onRemove():void { myProxy = null; myView.removeEventListener( MyView.VO_SELECT, handleVOSelect ); setViewComponent(null);
}
// View component cast to actual type private function get myView():MyView { return viewComponent as MyView; }
// cache refs to frequently accessed proxies private var myDataProxy:MyDataProxy;
Also note, in the above scenario, both interactions with MyDataProxy were asynchronous. This a typical Mediator / Proxy communication pattern; invoke a proxy method and (possibly) be interested in resulting Notification(s).
Lets imagine some of the methods on the Proxy are synchronous; that they return results immediately.
For instance, a Command, typically executes a block of logic, during which it needs inline access to data known to be held by the Proxy. Although a Notification from somewhere will have triggered the Command's execution, the Command itself will need to communicate synchronously with the Proxy.
Lets imagine another view component, SearchBox in the interface has a search text box and its SearchBoxMediator listens for an event sent when the user types a search string and clicks 'Search'. SearchBoxMediator responds by sending a SEARCH_FOR_VO notification, triggering the SearchForVOCommand, which might look like this:
// request the appropriate MyVO based on string search override public function execute(note:INotification):void { var myDataProxy:MyDataProxy = facade.retrieveProxy(MyDataProxy.NAME) as MyDataProxy; var searchString:String = note.getBody() as String; var id:String = myDataProxy.findVO(searchString); myDataProxy.getVO(id); // MyViewMediator is interested in the result and will display the VO }
-=Cliff>
|