Calyxo Control Concepts

Calyxo has been designed to ease the development of JSP Model 2 applications. In a Model 2 application servlets take over the controller part and JSPs are used as view technology.

The Calyxo controller realizes the Command and Controller strategy. This strategy builds on the Front Controller and Application Controller design patterns. The Front Controller, implemented as a servlet, acts as a centralized access point for incoming requests. It delegates to an Application Controller (module), which is responsible for identifying and invoking Command Objects (actions) and for identifying and dispatching to views.

Note
Please refer to the Calyxo Base Concepts section as a prerequisite to fully understand Calyxo Control.

Let's introduce the major participants in the controller game.

Module Servlets

Each module is associated with its own module servlet. For an incoming request, the current module is selected by the servlet container. According to the servlet's url mapping a module may be selected by either a prefix- or extension mapping.

The servlet then extracts the module-relative action path from the request URL and invokes the current module's process() method, passing over the request, response and action path.

Modules

The module digs for an action to be invoked for the requested action path. The action's command, consisting of a sequence of filters and a core action command implementation, is then executed by the module.

A command's execution results in a dispatch configuration, which states how to finish the action processing cycle. This final action processing step is performed by a dispatcher. E.g., a dispatcher might delegate to another action (optionally within another module) or to a context-relative resource path (like a JSP).

Actions

A module is a container for actions. Each action is associated with a module-relative path. Depending on the incoming request, the module selects and invokes an action.

An action by itself may consist of a core action command implementation, a set of parameters, a chain of filters, exception handlers and a dispatcher.

Providing action command implementations is your part. They are the controller's end, from where you may invoke your application specific business logic. Action command implementations provide the core processing of an action.

Filters

A series of filters may be attached to an action. The module combines these into a chain, appending the core action command as the last link. The chain presents itself as a command, which is initially executed by the module.

A Filter intercepts the chain's execution. As a link in the chain it executes the remaining chain and may perform preprocessing, postprocessing or both. It may even decide to not execute the remaining chain.

Exception Handlers

If an action's invocation throws an exception, the module searches for an exception handler and - if it finds one - executes it. Exception handlers may be declared for a hierarchy of exception classes either local to an action or global to the module. Local handlers precede over global handlers.

Dispatchers

An action invocation results in information on how to dispatch. Dispatching is the final step in action processing. This might result in delegating to another action (optionally within another module), to a JSP or to an external location. Dispatching might use a forward, include or redirect.

The default dispatcher does all this. However, in certain cases special treatment may be desired. Therefore, customized dispatchers can be implemented and used.

Plugins

Plugins provide a way to extend the controller by executing code during module initialization and finalization. The Plugin API is used to register filter classes by name and to bring custom dispatchers into the system.