I almost always use push. The model is informing (via an event) that its state has changed, and offering a new snapshot for interested parties.
There are two situations where I use pull:
1) Where I have more than one instance of the same view and I want to only refresh this one (imagine a grid of news stories and being able to click a 'change' on any one story to get a new one instead).
2) Where the view arrives after the model has last dispatched a state change.
In the first case I use a sync-signal request-response pair. Basically I inject into the mediator a 'request signal' which has been mapped to a command. The argument for the signal is another signal, which requires the model's vo as an argument. The mediator creates this response signal and dispatches it on the request signal. The command is fired, grabs a vo from the model, and uses the response signal which the mediator passed as an argument to send this vo back to the same mediator that fired the request.
In the second case I now use an implementation of the eventMap which I call the 'relaxedEventMap'. It basically allows you to keep event history and get the last instance of the event, so that the view can arrive after the model last updated and pick up the event that the model last sent. Effectively this is a pull, but the pull is wrapped in the relaxedEventMap and is being executed in there, pulling from its history.
Can you explain me on an example http://insideria.com/2010/06/an-introduction-to-robotlegs-a-1.html ?
private var _selected:Author;
public function get selected():Author
public function set selected(value:Author):void
_selected = value;
dispatch(new SelectedAuthorEvent(SelectedAuthorEvent.SELECTED, selected));
Would you behave likewise? What if I have another "selectedField" in that model? Should I create SelectedFieldAuthorEvent?