Customizing the Request Processor

When the Struts controller dispatches a request to a specified path (through a forward or include), the plugin checks, if that path is the name of a toplevel panel definition. If so, it causes the controller to dispatch to the panel's associated template, instead. Otherwise, the request is dispatched to the specified path, as usual.

Struts 1.3

Struts 1.3 provides org.apache.struts.chain.ComposableRequestProcessor which allows to configure the request processing chain via XML. To use Calyxo Panels with this processor, the de.odysseus.calyxo.struts.panels.PanelsCommand must be added to the chain.

The Calyxo Struts jar contains a chain definition which emulates Struts 1.2 and adds the Calyxo Panels commands. Refer to the configuration section on how to use it. A copy of the modified chain config file is located in calyxo-struts/conf/share/calyxo-panels-chain-config.xml.

If you need to specify your own customized chain configuration, you will need to include the Calyxo Panels command yourself.

Struts 1.2

Under Struts 1.2.x, intercepting the process of request dispatching requires subclassing the module's request processor class. Therefore, the panels plugin comes with its own processor class. The plugin will automatically cause Struts to use this processor class as default.

However, if an application wants to use a custom processor class, it must extend the plugin's processor class!

In the Struts configuration file, the request processor class may be specified using the processorClass attribute of the <controller> element. For the panels plugin to work, the request processor class used must be the same or a subclass of de.odysseus.calyxo.struts.panels.PanelsRequestProcessor.