Just a (very small) suggestion for the next big release of PureMVC:
It'd be very handy if the Facade's registerMediator and registerProxy methods would return the instance of the mediator/proxy which gets registered.
That way you can write this:

:

mediator = facade.registerMediator( new SomeMediator( someView ) )instead of:

:

mediator = new SomeMediator( someView );
facade.registerMediator( mediator )
I know, it's a silly and small thing, but everything which speeds up coding is welcome

Thanks for the excellent demo. There's just one thing though, I think it would be better to handle the loginpanel through a separate mediator instead of the ApplicationMediator...

Great job!!

I've used two possible solutions for this situation (I have no idea whether these are the best solutions, though...)
1. Create a mediator for each itemrenderer and let the mediator communicate with the authors proxy to look up the author name, using the author id
2. let the item renderer send a dataChange event to the view's mediator, which in turn does the same as in 1.

Whether I choose 1 or 2 depends on the complexity of the itemrenderer. If it needs to get data from various proxies and performs all kinds of difficult logic, I'll choose 1. It's a more convoluted solution since you'll need to create the extra mediator-class and most probably a factory class as well.

Probably I'm overlooking something very basic here, but why not create a proxy (not a pureMVC proxy, in this case) for the webservice that calls CursorManager.setBusyCursor() and CursorManager.removeBusyCursor() when the service is respectively called and finishes its call?

Q1: if you turn it into a singleton, you can only send one notification at a time. Which would be a serious downgrade.

Q2: this.getNotifyMethod().apply(this.getNotifyContext(),[notification]);
means:
apply the result of getNotifyMethod (that result is a function) to the result of the getNotifyContext and pass the retrieved function the value of "notification" (the apply method takes an array of possible arguments, therefore notification is enclosed within [])

Q3:
It provides a way for a class to define what method should be invoked when a notification is received.

For instance in Controller.registerCommand there's the line (#136)
view.registerObserver( notificationName, new Observer( executeCommand, this ) );

Controller passes it's own "executeCommand" method to the Observer constructor ( that method is stored in the "notify" property of the Observer class) So, whenever the getNotifyMethod of that Observer instance is called it will return the "executeCommand" method of Controller.
As a second parameter it passes "this" (which is the instance of the Controller class) which gets stored inside the Observer instance in the "notifyContext" property. So, whenever the getNotifyContext is called it will return the controller instance.

Whenever the notifyObserver method of an Observer instance (used in the Controller class) is called it will run the "executeCommand" method on the controller instance. (This, obviously, only applies to all Observer instances used in the Controller class, Observer instances in other classes will return other methods and other contexts)

When navigating from one page to another clean up the mediators you don't need anymore. Which is best practice BTW.
So yes, in this case, being lazy is bad.

Just to let you guys know the swfObject template works like a charm. Very easy-to-use.

Sounds like you have the right reasons to have the image mediators, so I wouldn't drop that. My guess would be that the problem lies in how the mediators are instantiated. What way do you differentiate between the instances? Do you have a factory class, which keeps track of the various instances or ... ?

Ah, yes, should've mentioned it can only be used in Flex.

Thanks a bundle for the response, it's much more clear now!

I don't know if anybody'll have any use for this, but I wrote a small function which defers the registration of the mediator until the view component it mediates is created.
(I hope it doesn't sin against the best practices ??)

Place this in ApplicationFacade:

:

public function deferMediatorRegistration( mediatorClass : Class, viewComponent : UIComponent ) : void{
var facade : ApplicationFacade = this;
var listener : Function = function( event : FlexEvent ) : void {
facade.registerMediator( new mediatorClass( event.target ) );
}
viewComponent.addEventListener( FlexEvent.CREATION_COMPLETE, listener );
}
to use it (in, for instance, ApplicationMediator )

:

ApplicationFacade.getInstance().deferMediatorCreation( MyCustomMediator, app.myCustomComponent );


Thanks for the swift reply and action. Cliff, you really are one of the major advantages of this framework
I hadn't realized that some of the tutorials didn't follow best practices entirely (are there others?)
Just one more thing: in the best practices document you write:

Commands house the business logic of our application

(p. 18) and a few lines further:

The Model maintains its integrity through the use of Proxies, which house domain logic and [...]

When I look up "business logic" and "domain logic" at wikipedia both phrases lead me to the same article. Could you explain the difference to me? Or point me to a site which does?
I'm sorry for such noobish questions!

Excellent tutorial, thanks a lot!

I'm a bit confused about the responsibilities (and use) of commands. When I look at the provided examples I notice there are examples where all remote access is done through commands ( for instance there are commands for all CRUD operations in the Bookstore example)
But then in another example (IndexCards) all remote access is done through the proxies.
I'm not sure which approach I need to take.
I'm working on an application with around 20 tables and approximately the same amount of views. If I cut up all CRUD operations to separate commands this'll give me 60+ commands. That seems WAY overkill. But on the other hand if I go for the proxy-approach, I'll only have 3 (Startup, ModelPrep and ViewPrep) and suddenly commands seem completely useless to me.
So, when should I decide to put something into a command and when can I leave it to the proxy?
(I read the chapter on commands in the "best practices" document, but I must confess that I'm not familiar with most of the expressions like 'domain logic' etc. Looking them up at Wikipedia didn't make me any wiser, on the contrary)

You've got a point there.
But when it's not shown in a browser all external assets are still placed in a temp directory, so the same principle applies. (If I remember correctly the cache won't be re-used in a new session though, which is a difference with the browser's cache)