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: Creating Methods To Retrieve Data From Proxies  (Read 6670 times)
toadrage
Newbie
*
Posts: 6


View Profile Email
« on: August 14, 2009, 08:51:22 »

Hi there,
Ok so after loading in my XML, I create a bunch of Value Objects, insert them into an array and then register a proxy which passes in that array.

My question is, how and where do I write code to interact with that proxy?

Basically, each value object will have an id and I would like to write a function that takes an ID as a parameter, then loops through the array of value objects and if one of their IDs matches the passed parameter, returns that value object.

Before PureMVC, I would have my array stored in a singleton somewhere and then I would write static functions to deal with this kind of thing.  However, I can't seem to find a way to first retrieve the proxy and then start using my own functions written inside that proxy.  For that matter, should I actually be writing my own functions INSIDE a proxy for these sorts of things?  I will want to be doing this kind of searching functionality quite a lot throughout my site.

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



View Profile WWW Email
« 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>
« Last Edit: August 15, 2009, 07:43:12 by puremvc » Logged
Pages: [1]
Print