Here is the solution that I ended up using for this particular problem:

:

public class ApplicationMediator extends Mediator implements IMediator
{
public static const NAME:String = 'ApplicationMediator';

public function ApplicationMediator( viewComponent:Object ) {
super( NAME, viewComponent );
}

override public function listNotificationInterests():Array {
return [ApplicationFacade.POP_UP_VC_ADD];
}

override public function handleNotification( note:INotification ):void {
    addToNotificationsReceived( note );
switch ( note.getName() ) {
   case ApplicationFacade.POP_UP_VC_ADD:
this.onPopUpAdd(note.getBody());
    break;   
}
}

private function onPopUpAdd(popUp):void
{
                    PopUpManager.addPopUp(popUp, this.viewComponent, true);
                    PopUpManager.centerPopUp(popUp);
}


In this situation, you'd want to derive the mediator names from the unique fields of the VOs you are working with.

Thanks Cliff,

I am happy that I was on the right track.

I think I am going to end up with some ridiculously long winded mediator names 

Cheers,
Derek

mapItem isn't typed here, so I don't know what it is, but there is nothing wrong with using the type field as a discriminator so that only one of the notified Mediators will respond.

-=Cliff>

Thanks Cliff!

Derek Basch

So, note that monitor.reset() now does a facade.removeProxy for SRP objects.  If this is a problem for anybody, please let me know.

I believe this is the correct behavior. I was manually removing them before.

Thanks,
Derek Basch

Hello all,

I am trying to figure out the best way to handle the grouping of mediators. For example, let's assume that we have a library with books, book chapters and book pages.

BookMediator_AtlasShrugged
	ChapterMediator_1
	ChapterMediator_2
		PageMediator_1
		PageMediator_2
BookMediator_AnarchistsCookbook
	ChapterMediator_1
	ChapterMediator_2
		PageMediator_1
		PageMediator_2

It seems that the only way to ensure that notifications are sent to the proper PageMediator is to have a naming schema established. Something like this:

"BookMediator_AtlasShrugged_ChapterMediator_1_PageMediator_1"

However, this requires that the name of any "parent" mediators be available to PageMediator when it is instantiated. I must be missing something here.

As an example, let's step through an "Add Page" command followed by a "Set Page Font" command with some psuedocode.

:


PageVO:
text:String = "It was the worst of times, it was the..."
FontVO:
font:String = "WingDing"

---------------------------------------

BookProxy.addPage(pageVO):
facade.sendNotification(ApplicationFacade.ADD_PAGE_CMD, pageVO)

AddPageCommand:
// HOW DO WE DETERMINE THE NAME TO GIVE TO THE MEDIATOR HERE?
facade.registerMediator(new PageMediator("BookMediator_AtlasShrugged_ChapterMediator_1_PageMediator_3"));

// HOW DO WE DETERMINE WHICH BOOK AND CHAPTER TO ADD THE PAGE TO HERE?
facade.sendNotification(ApplicationFacade.ADD_PAGE_VC, pageVO, "BookMediator_AtlasShrugged_ChapterMediator_1_PageMediator_3")

---------------------------------------

PageMediator.setPageFont(fontVO):
facade.sendNotification(ApplicationFacade.SET_PAGE_FONT_CMD, fontVO,  this.getMedatorName())

SetPageFontCommand:
// HOW DO WE DETERMINE WHICH PAGE TO SET THE FONT OF HERE?
facade.sendNotification(ApplicationFacade.SET_PAGE_VC_FONT, fontVO,  "BookMediator_AtlasShrugged_ChapterMediator_1_PageMediator_3")

---------------------------------------

What techniques is everyone using to deal with this sort of issue? Should I add the grouping information to the Value Objects? Should I be trying to retrieve the grouping info from a Proxy?

Thanks,
Derek Basch

Hi all and Cliff,

I often need to have a command execute against specific mediators. Is it incorrect to use notification typing in a command?

:

public class AddAssetCommand extends SimpleCommand implements ICommand {

override public function execute( note:INotification ):void {

var newAssetVO:Asset = note.getBody() as Asset;

var mapInstanceUID:String;

// if we didn't get a map instance Id
// then use all the viewable maps
if (note.getType() != null) {
mapInstanceUID = note.getType();
} else {
var mapProxy:MapProxy = facade.retrieveProxy("MapProxy") as MapProxy;
for each (var mapItem in mapProxy.mapCollection) {
facade.sendNotification(ApplicationFacade.ADD_ASSET_CMD, newAssetVO, mapItem.mapUIComponent.map.name);
}
return;
}


One last note, there does not seem to be a good example of using a single Proxy as both invoker and responder of an asynchronous service call. All of the examples use either hard coded VO's or use the delegate pattern.

I take it back. I found the Code Peek demo under the AIR examples. It uses a "SearchProxy" and a "DataProxy".

I usually name my proxies something like this:

Data Proxies:

• VegetableProxy
• CowProxy
• ChickenProxy

Service Delegate Proxies:

• FarmServiceDelegateProxy

Many implementations of the Delegate pattern in the wild are actually instantiated once for each caller and provide a separate service object that is being used solely for that caller. This is pretty wasteful since you can reuse a Flex service object for multiple callers use the AsyncToken pattern to sort out which returns go to which callers.

So actually a good way to handle this in PureMVC entirely with Proxies is to register a Proxy that acts as the Delegate. Other Proxies call methods on it passing themselves to be used as the responder.

Why is ths any better than having a Delegate that does the same thing? Because its long-lived, easily retrievable, and only one service object is used.

-=Cliff>

Yes, exactly! I wrestled with this issue several months ago and found a similar solution. I started using Proxy objects as proxies (or delegates) for service endpoints.

One Proxy for the data set being managed (Chair inventory) and another for the service endpoint (Chair service) being managed.

As always though, Cliff did it better than I could have. 

One last note, there does not seem to be a good example of using a single Proxy as both invoker and responder of an asynchronous service call. All of the examples use either hard coded VO's or use the delegate pattern.

Cheers,
Derek Basch

This is very good info regarding WHERE to instantiate dynamic proxies as well. I was confused about whether instantiating mediators within another mediator was proper. Thanks Cliff.

Derek Basch

Hi Derek,

Sounds reasonable. As with any open source project you are empowered to make it better!

How about checking out the trunk, making your suggested changes, test them in your app and then create a patch and post it here?

You could extend the existing demo or create another to show how it works.

-=Cliff>

Thanks for the reply Cliff. I will do what you suggested.

It appears that it is time for the StartupManager to become the ApplicationStateManager.

That is the way I am using it at least. But, I like to put round pegs in square holes 

Regards,
Derek Basch

You asked for feedback on the usage of this great little tool so here it goes:

Here is my wish list:

• I have been messing around, using this tool, for sequential data model loading after the initial startup sequence. I often find myself wishing that I could dynamically register resources with the same singleton monitor instance instead of having to instantiate a new singleton monitor repeatedly. I imagine the sequence would go something like this:
  • Check that the singleton monitor instance isLoadingFinished is true. This is currently a private attribute and listening for the LOADING_COMPLETE notification does not work within a command (createNewMonitor command for instance) as they don't listen for notifications.
  • Set the resourceList to empty
  • Dynamically register any new proxies that we may need
  • Call monitor.loadResources
  • You essentially do these same steps when you re-instantiate the monitor so why not cut some of the overhead?
  
  
• I often wonder why the doRetryLoadResources() function doesn't start from the resource that is AFTER the last known properly loaded resource. The other resources have loaded properly so why do we get them again?

Thanks for the great tool and hopefully this was constructive 

Regards,
Derek Basch

Thanks for making the great tool. I have an issue with it though.

I am using the Startup Manager to monitor a Remote Proxy. Ideally, the remote proxy would perform different queries based upon the query type passed to it's search() function. However, this creates a problem because the load() function of the Startup Manager is called without any parameters. Therefore, I can't do this:

:

public function load(queryType) :void {
    this.search(queryType);
}

The only solution I have found is to set a queryType property on the Remote Proxy before registering it with the monitor.

:

remoteProxy.queryType = "customerQuery";

....register proxy with monitor..blah..blah...

public function load() :void {
    this.search();
}

public function search() :void {
    query(this.queryType);
}

Any suggestions on how to cope with this? Maybe load should accept some parameters?

Thanks,
Derek Basch

Thanks for the reply Cliff. Keep up the good work

I think I got my head around this a bit more now. I was reading the prior version of the Implementation document and it didn't cover this topic as well and the more recent version. I think this snippet says it all:

Mediators may freely retrieve Proxies from the Model, and read or manipulate the Data Object via any API exposed by the Proxy. However, doing the work in a Command will loosen the coupling between the View and the Model.

I do often see Mediators calling functions of Proxies in the example code. However, it looks like they are one way calls and the Proxy functions are not expected to return a value, but rather, to set a value on their encapsulating Proxy that is later retrieved.

A quick question for everyone. There seem to be two ways for Mediators to interact with Proxies in PureMVC

1) A Mediator responds to a Notification and uses the body of the Notification within the Mediators view level logic.

2) A Mediator responds to a Notification and calls a public function of a Proxy. The functions return value is used within the Mediators view level logic.

Which is better? It seems to me that method #1 couples the view to the model pretty heavily. Is it simply up to the developer depending on the level of layer decoupling that is desired?

Thanks,
Derek Basch