In PureMVC, the "Mediator":http://en.wikipedia.org/wiki/Mediator_pattern design pattern is used to mediate between the view and the framework. This reduces coupling, as the view knows nothing about the framework (if you're importing any org.puremvc classes into your view, you're doing it wrong), and knowledge of the view's public API is limited to the Mediator which manages it. To kick things off we pass the view component to the Mediator, and register it with the framework:
<code lang="actionscript">
public class ViewPrepCommand extends SimpleCommand
{
facade.registerMediator( new TagCloudViewMediator( new TagCloudView ) );
}
</code>
The Mediator itself should provide limited functionality. It should advertise which notifications it's interested in (via its listNotifications method, which is queried when the Mediator is registered via the facade), and respond to those same notifications by manipulating the view it mediates for. For instance, in our tag cloud example, we want to know when data about the tags has been received, and then retrieve this data from the relevant proxy and pass it to the view:
<code lang="actionscript">
override public function listNotificationInterests():Array
{
return [ Notify.TAGS_LOADED ];
}
override public function handleNotification( note:INotification ):void
{
var name:String = note.getName();
switch( name )
{
case Notify.TAGS_LOADED:
view.setData( getTags() );
break;
}
}
private function getTags():Array
{
return remoteProxy.getTags();
}
private function get view():TagCloudView
{
return TagCloudView( viewComponent );
}
private function get remoteProxy():RemoteProxy
{
return facade.retrieveProxy( RemoteProxy.NAME ) as RemoteProxy;
}
</code>
As you run through this example, you'll see that there isn't much to our TagCloudMediator. That should be true of most mediators, if you find yours are much heavier than this or rely on a variety of private setup functions you should seriously consider moving this application logic to a command. We've already touched on the @listNotificationInterests@ method, so moving on you can see that the @handleNotification@ method determines how to act based on the name of the notification. In our case we're only interested in Notify.TAGS_LOADED, and once this occurs, we pass the relevant data to the view.
One style we've settled on is to use an implicit getter called view() to cast the viewComponent Object to the specific type and return it. 'tagCloudView' is perhaps more descriptive, but there are certainly benefits in only having to locate and parse 'view' as you work across multiple mediators within an application.
You'll notice we get tags via the RemoteProxy, so it's a good time to back up, and look at the @ModelPrepCommand@ we skipped over a little earlier:
<code lang="actionscript">
public class ModelPrepCommand extends SimpleCommand
{
override public function execute( notification:INotification ):void
{
super.execute( notification );
facade.registerProxy( new FlashVarsProxy( Application.application.parameters ) );
facade.registerProxy( new RemoteProxy() );
}
}
}
</code>
Here we register two proxies: a new FlashVarsProxy, which is used to store and return any variables set on the swf file from within the html, and a RemoteProxy, which is reasonably straightforward. We're calling it the @RemoteProxy@ because in this simple example it is the one and only proxy for accessing remote data. In the next post I'll run through our RemoteProxy in detail.
2008-12-09T21:28:14Z
0
28
basic-architecture-of-a-puremvc-application-part-ii
Basic Architecture of a PureMVC Application: Part II
2009-04-21T07:24:36Z