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.
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.
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.
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).
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.
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
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.
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
The default dispatcher does all this. However, in certain cases special
treatment may be desired. Therefore, customized dispatchers can be
implemented and used.
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.