Route per-view lifecycle events to the correct user methods.
The name "view" is used for the resource that the user has accessed. For example with JSF either one or two views are accessed per user request; possibly a "postback" and always a "render" view. Orchestra adaptors for other UI frameworks select an interpretation of the name "view" appropriate for that framework.
Orchestra retrieves a concrete implementation of this interface and invokes it at the appropriate processing phases. Exactly what those phases are depend upon the underlying UI framework. The concrete ViewControllerManager is then responsible for determining which beans should receive callbacks (based upon the resource that the user has accessed)
Orchestra provides a default implementation of this interface; see {@link DefaultViewControllerManager}.
Defining your own ViewControllerManager
If you would like to customise the way beans are located for a view, or which methods are invoked on them then either
- Implement this interface directly, or
- Subclass {@link AbstractViewControllerManager} (the recommended way).
To activate your custom manager, configure it as a managed bean (preferably in application or singleton scope), using the bean-name org.apache.myfaces.orchestra.viewController.ViewControllerManager
(see constant {@link ViewControllerManager#VIEW_CONTROLLER_MANAGER_NAME}).
How the ViewControllerManager is invoked
Each UI framework needs to ensure that the ViewControllerManager is retrieved via the special name shown above, and invoked at appropriate times. For example, for JSF see class @{org.apache.myfaces.orchestra.viewController.jsf.ViewControllerPhaseListener}; this is automatically configured for JSF applications when the orchestra jarfile is placed in the classpath.