javax.swing.JPanel
or something conceptually similar) and the control code lives in an associated controller class. The controller philosophy is thus: The panel class (and its UI components) convert basic user interface actions into higher level actions that more cleanly encapsulate the action desired by the user and they pass those actions on to their controller. The controller then performs abstract processing based on the users desires and the changing state of the application and calls back to the panel to affect changes to the display.
Controllers also support the notion of scope. When a panel wishes to post an action, it doesn't do it directly to the controller. Instead it does it using a controller utility function called {@link #postAction}, which searches up the user interface hierarchy looking for a component that implements {@link ControllerProvider} which it will use to obtain thecontroller "in scope" for that component. That controller is requested to handle the action, but if it cannot handle the action, the next controller up the chain is located and requested to process the action.
In this manner, a hierarchy of controllers (often just two: one application wide and one for whatever particular mode the application is in at the moment) can provide a set of services that are available to all user interface elements in the entire application and in a way that doesn't require tight connectedness between the UI elements and the controllers.
|
|
|
|
|
|