Analysis Model Classes

Each controller is a single objectwhich may have many helper objects, if necessarybut all support a common interface. A key element in this mechanism is that the Web application server is configured to route all incoming requests through a single class: one object instance for each user session. This object is the RequestProcessor.

At the heart of this mechanism is the coordinator, an object that manages all the active controller instances for a particular user. When a user begins using the application, the default controller is pressed into service and manages all the user page resource requests. A different controller can be requested to take control of the user session, by specifying it as a parameter in a URL hyperlink. This implies that at least some hyperlinks in the application will have knowledge of the other controllers that can be activated and used by the user. (A good example of this is a common menu HTML component whereby each hyperlink in it specifies the controller that manages that activity.)

When it sees a request for a new controller, the coordinator first checks with the active controller to ensure that it doesn't require exclusive controlfor example, in the middle of an important scenario that cannot be postponed. If it doesn't, the current controller is placed on a stack, and the new controller is made the current one. All subsequent page resource requests are managed by this controller until it is completed.

When a controller is completed, the coordinator removes it from the active stack, and the next controller on the top is made the current active controller. (If there are none on the stack, a new instance of the default controller is created.) Figure C-5 shows an analysis-level diagram of the coordinator and its relations to the individual controllers.

Figure C-5. Main analysis-level class diagram for mechanism

Each controller must be able to accept an incoming HTTP request for a page resource, process any parameters or field data, update the state of the business, and identify the next page resource to send to the requester. In some situations, the requested page resource cannot be returned to the user, and a different one is sent. For example, the user might submit payment information, and normal flow would be to the page that redisplays this information and prompts for confirmation. If the data was invalid, the requested pagepayment confirmationshouldn't be returned; rather, the payment information request page should be, with an informational message indicating the invalid information. The controller is responsible for processing the payment information and determining which of the two response pages should be sent back.

Each response page may interact with the state of the business in order to get and to assemble the dynamic content in each page. It is also expected that each "page builder" can easily get a reference to the current active controller, which provides a convenient access point to the business state. Figure C-6 shows an analysis diagram of the controller and its relationship to the individual page builders and page user interfaces.

Figure C-6. Sample set of controllers