ActionScript Developer's Guide to PureMVC

Chapter 6. Mediating the View

As the old saying goes, communication is a two-way street. That is the central truism of the Mediator’s existence.

The Mediator exists to facilitate two-way communication between a View Component and the rest of the application. Therefore, the bulk of the Mediator’s responsibilities will be handling Events from the View Component and Notifications from the rest of the application. This decouples the other actors in the application from the component and vice versa.

If a Mediator is the only class in the application that actually knows a View Component, and the implementation of the component has to change, the impact to the rest of the system will be minimized. And if the View Component has been properly encapsulated, changes to the internal implementation (such as changing a List to a ComboBox) will not change its collaboration patterns or have any impact at all on the Mediator.

The Mediator class has a facade property: a reference to your ApplicationFacade. It can register, remove, and possibly retrieve other Mediators, Proxys, and Commands. It has this property by virtue of being a Notifier subclass, where it also gets its sendNotification() convenience method. Of all these things, only retrieving other Mediators is considered a bad practice. We will discuss that below.

Mediator Life Cycle

Generally, you will pass a View Component into a Mediator subclass constructor, most often in the “view preparation” phase of your StartupCommand. When the main application ...