What brings the ‘rich’ to our rich internet applications? The beautiful, animated, interactive, lovingly crafted view components that users interact with. These view components and screens can be created in any number of ways. They might be complex Flex components or pure ActionScript using low level graphics APIs. No matter how your views are developed they will need to communicate both with other views and with the services and models we discussed in chapter 7.
This is where
Mediators come in.
Mediators are lightweight classes that create
a bridge between your view tier and the rest of your application. Mediators
act as switchboards. They listen for important events that the view needs to
respond to, and dispatch events to let the rest of the application know when
something changes in your view—usually because of user interaction.
As with other managed objects, we need to tell Robotlegs which views
connect to which mediators. This process is accomplished by using the
MediatorMap. The MediatorMap is a core object that is created for you by
Context. Lets take a look at how
the MediatorMap works.
The MediatorMap is available by the time the
Context runs the startup() method. It is also
available in commands that extend the Robotlegs
Command class, or you can inject it (as
into your own commands. In the most simple applications we will map our
views within the