Content

Controller

Application flow processing is in Gaia realized by different instances of Controller class.

Controller is an abstract superclass for all controllers. It supports the basic infrastructure for a controller lifecycle and communication.

Each controller is a singleton. The requested instance can ba accessed by the static method getController(String). Hence there is no space in the controller variables to store user data. For this purpose exists the Context class instances. You can imagine it as a map of {name:value} entries for your free usage.

Each client has just one server Application at the time and just one current Context instance.

When the controller is requested from the client, the Application finds (or creates) its singleton instance via method getController(String) method. Then Application invokes its method process(ApplicationRequest, Context) to process the client request. Controller prepares the server response (for example data to display in some form) and returns it as the return value from this method.

With the next request (for example, user pressed some button on the form), the Application invokes method forward(ApplicationRequest, Context) on it. This is the standard, unchangeable behavior. The runnning controller should process data from the client before it processes requested action (they are delivered together in one ApplicationRequest instance). The request can be in forward() method forwarded to the other controller, or can be processed in a local method - it is a matter of the implementation or configuration.

If the incoming request is to be forwarded to the other controller, the forward() method first invokes createContextForForward(ApplicationRequest, Controller, Context) to create a new context. Override it to initialize the new context with data from the current context. Then is invoked process(ApplicationRequest, Context) method on the requested controller.

There are two ways to return control to the calling controller:

1. invoke method returnSuccess(ApplicationResponse, Context) - this invokes method success(ApplicationResponse, Context) on the calling controller, which closes current context and prepares its parent context to be current and itself to be a running controller
2. invoke method returnFailure(ApplicationResponse, Context) - this invokes method failure(ApplicationResponse, Context) on the calling controller with the same effects as described above

In the Controller class is implementation of methods success() and failure() the same. But it will differ in subclasses. The first indicates that called controller does its work successfully and data are possibly changed. The calling controller should probably update its data. The second method should be used when something goes wrong (for example, an user pressed CANCEL button) and there is no change in data.