I decided to take my flex development to the next level and learn PureMVC framework in a week.

I will be:
- studying framework documentation.
- reading blogs, tutorials and forum posts.
- learning from source codes.

Documentation:
PureMVC_Implementation_Idioms_and_Best_Practices.pdf

PureMVC Forum posts:
First project with PureMVC
Having difficulties changing views
User Manager Demo (PureMVC+WebORB+PHP+MySQL)
Notification, “type” property?
Popup Window
Multiple delegate service parameters in different views
Document-Based Application: is PureMVC the way to go?
creating and destroying mediators at runtime
Registering Multiple Instances of one Mediator and Proxy: A Best Practice
Remote Objects
Yo Cliff! Why the connection between the mediator and the proxy?
Does mediator sendNotification to proxy or they can call directly ?
Accessing properties on components from Commands

Blogs:
Minimalist MVC example using the PureMVC
10 tips for working with PureMVC
Flex, PureMVC, Jabber and XIFF 3
PureMVC Notifications
PureMVC Roundup
Flex, Coldfusion and MySQL PureMVC style
Creating an AIR RSS Reader Application from Scratch with Flex and PureMVC
Building a flash site using PureMVC
From Cairngorm to PureMVC : a quick comparison
Getting started with the PureMVC Startup Manager – Introduction

Other:
PureMVC Introduction(slideshow)
Intro to PureMVC(video)
We prefer PureMVC because…(presentation)

NOTES:
Thus Proxies send but do not receive notifications, while Mediators and Commands may retrieve and interact with Proxies directly.

Boilerplate code: creating Mediators and Proxies can be quite tedious – I find my spirits drop a notch whenever I need to create one of them.. “Ok, let’s do this thing! Woo! Create New Class.. Must extend some class and implement some interface.. and define my static NAME constant.. and.. ah.. create a getter to cast my view.. and.. override onRegister to hook up my view listeners.. and override listNotificationInterests.. and handleNotification.. and viola! I can start coding!” Actually, that’s first time I’ve listed it our for myself – should keep that for next time

Highly recommended.

(Buy from Amazon)

…the mediator to do jus that; mediate. Take events from the component and turn them into notifications for the rest of the system, or to take notes of interest and respond by setting data on the component or calling methods on it to change its state or otherwise alert it of the system’s desires where it is concerned. And occasionally to create mediators for the view component’s chindren. That’s about it for mediator responsibilities.

Now, constants common to the model itself define on the proxies (such as ProductProxy.PRODUCT_RETRIEVED) or in a separate class (such as CommonConstants.PRODUCT_RETRIEVED).

Sounds about right on the creation, but on destruction, a better way to go is that the ContentMediator removes the subpage from its view component’s hierarchy. This will cause the subpage component to send a REMOVED event which its mediator should listen for and respond to by removing its listeners, nulling its viewComponent reference (freeing the subpage for GC) and finally removing itself with ‘facade.removeMediator(this.getMediatorName());’

Why make a model class that reflects dynamic properties of the view? The Model is for data about the domain, not the View. the view component (stage, button or whatever) is in charge of holding its properties, so query it (through a mediator) if you need to know its properties.
The only time you’d want to store these properties in a Proxy is if you will be persisting them (in which case those properties are now actually part of the domain). – by Cliff

Your mediators for your view components just feed data to the components and listen for events from them. For instance a mediator can set the currentState property of a component that causes it to change state, which might lead to a visual transition. This is best encapsulated in the component itself rather than orchestrated by other actors. – by Cliff

For application wide state management have a look at the StateMachine Utility. This differs from Flex view states in that it isn’t pertaining to a particular component’s composition, but rather to the state of the entire system. So in the ‘logging in’ state you might be displaying a login panel. When the user enters the info and clicks a login button, the component sends an event that the mediator is listening for. The mediator takes the values either from the event if it is a custom event, or simply interrogates its login component for the info (expose a getCredentials method or top-level props like username and password). Then the mediator may retrieve a LoginProxy that makes the login call and later sends an appropriate notification when it gets a result or fault. If it’s a good result, this may then lead to a command kicking the state machine into its next state, lets say the ‘display products’ state. An interested mediator may hear the ‘changed’ notification sent when the state machine reaches its ‘display products’ state, causing it to remove the login box and display products.
by Cliff, topic: need advice for rewrite existing flex app using puremvc

Certainly do expose value objects to your view components. The primary benefit of a value object is to act as a data carrier to shuttle data across the tiers of your app…That said, obviously its a good thing to work out your domain model first, since constant churn in VO definition can cause you to be changing code all over the app across all tiers. The domain model is a cross-cutting dependency that is impossible to minimize.
by Cliff, topic: quick VO clarification-is it good practice to expose a VO to a views?

Above notes are just pieces of comments from PureMVC forum.
I encourage you to read many posts from that forum.