org.wandora.modules.servlet

Class ChainedAction

java.lang.Object

org.wandora.modules.AbstractModule

org.wandora.modules.ScriptModule

org.wandora.modules.servlet.AbstractAction

org.wandora.modules.servlet.ChainedAction

All Implemented Interfaces:

Module, ActionHandler, ServletModule.RequestListener

public class ChainedAction
extends AbstractAction

An action that makes it possible to chain together two, or more, actions into one. This is useful if you have an action that already fits the situation but needs one little thing added to it. For example, you could just use GenericTemplateAction, but you also want to send an email. You can chain together a SendEmailAction and the GenericTemplateAction with a ChainedAction. The ChainedAction is the action that receives the actual HTTP request, it then passes it on to the first action in the chain, if the action succeeded, it passes it on to the next action and so on. Note that in most cases only one of the actions in the chain should write anything in the response object.

You have other options as well to resolve the above use case. You could just extend GenericTemplateAction to make the action you need. Or, without extending the action, you could just pass in its template context a helper object that can do the other things you need to be done and then do them in the template.

To use this action, give the chained actions in an initialisation parameter named chain as a semicolon separated list. Each action in the chain must be named (using the name attribute in the module, like naming modules normally) and then the names used in the chain parameter. Usually you don't specify any action keys (the action or actions parameter) for the chained actions to prevent them from being used directly outside the chain. Although in some cases this could be desirable too.

Author:

olli

Field Summary

Fields

Modifier and Type	Field and Description
protected java.util.ArrayList<AbstractAction>	chain
protected java.util.ArrayList<java.lang.String>	chainNames

Fields inherited from class org.wandora.modules.servlet.AbstractAction

actionParamKey, handledActions, httpHeaders, isDefaultAction, replacements, replacementsInitialized, servletModule

Fields inherited from class org.wandora.modules.ScriptModule

engine, initScript, persistentObjects, scriptManager, startScript, stopScript

Fields inherited from class org.wandora.modules.AbstractModule

autoStart, isInitialized, isRunning, logging, loggingModule, moduleManager

Constructor Summary

Constructors

Constructor and Description
ChainedAction()

Method Summary

Modifier and Type	Method and Description
java.util.Collection<Module>	getDependencies(ModuleManager manager) Returns all the modules this module depends on.
boolean	handleAction(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp, ModulesServlet.HttpMethod method, java.lang.String action, User user) Handles this action.
void	init(ModuleManager manager, java.util.HashMap<java.lang.String,java.lang.Object> settings) Initialises the module.
void	start(ModuleManager manager) Starts the module.
void	stop(ModuleManager manager) Stops the module.

Methods inherited from class org.wandora.modules.servlet.AbstractAction

addHandledAction, doReplacements, handleRequest, isHandleAction, setActionParamKey, setHttpHeaders

Methods inherited from class org.wandora.modules.ScriptModule

getScriptEngine

Methods inherited from class org.wandora.modules.AbstractModule

isInitialized, isRunning, requireLogging, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Detail

chain

protected java.util.ArrayList<AbstractAction> chain

chainNames

protected java.util.ArrayList<java.lang.String> chainNames

Constructor Detail

ChainedAction

public ChainedAction()

Method Detail

handleAction

public boolean handleAction(javax.servlet.http.HttpServletRequest req,
                            javax.servlet.http.HttpServletResponse resp,
                            ModulesServlet.HttpMethod method,
                            java.lang.String action,
                            User user)
                     throws javax.servlet.ServletException,
                            java.io.IOException,
                            ActionException

Description copied from class: AbstractAction

Handles this action. Prior to calling this action, it's already been determined that this action should try to handle the action by either matching the action request parameter with the action id of this action, or this being the default action. Perform any operations needed here and then write the response into the response object. You will typically want to call setHttpHeaders to set the HTTP headers in the response after you know that you definitely will handle the request but before you write anything else into the response stream. If for whatever reason this method shouldn't handle the request after all, return false. Otherwise return true.

Specified by:

handleAction in class AbstractAction

Parameters:

req - The HTTP Request.

resp - The HTTP response.

method - The HTTP method of the request.

action - The parsed action id.

user - The logged in user, or null if not applicable.

Returns:

True if the action was handled and a response sent. False otherwise in which case other actions may try to handle this action.

Throws:

javax.servlet.ServletException

java.io.IOException

ActionException

getDependencies

public java.util.Collection<Module> getDependencies(ModuleManager manager)
                                             throws ModuleException

Description copied from interface: Module

Returns all the modules this module depends on. This method will be called after init and the dependencies are allowed to depend on the parameters passed to init. The modules that this module depends on must be returned as a collection. In addition, if any required module is not present, a MissingDependencyException should be thrown. Typically you will use the requireModule and optionalModule methods of the manager to make sure that the modules exist and add them to the collection. requireModule will automatically throw the exception too if the module is not found whereas optionalModule does not.

Specified by:

getDependencies in interface Module

Overrides:

getDependencies in class AbstractAction

Parameters:

manager - The module manager handling this module.

Returns:

A collection of modules this module depends on.

Throws:

ModuleException

init

public void init(ModuleManager manager,
                 java.util.HashMap<java.lang.String,java.lang.Object> settings)
          throws ModuleException

Description copied from interface: Module

Initialises the module. After constructor, this is the first method called in the life cycle of a module. It should not perform anything time consuming or anything with notable outside side effects. It should only read the parameters and initialise the module so that it can later be started. Note that a module being initialised doesn't mean that it necessarily will ever be started.

A ModuleException may be thrown if something vital is missing from the parameters or they are not sensible. In some cases you may not want to throw an exception even if vital initialisation information is missing. If, for example, it is possible that the module is initialised in some other way between the init and the start method calls. A ModuleException may also be thrown at the start method if the module is still not initialised.

Specified by:

init in interface Module

Overrides:

init in class AbstractAction

Parameters:

manager - The module manager handling this module. You may keep a reference to it if needed.

Throws:

ModuleException

start

public void start(ModuleManager manager)
           throws ModuleException

Description copied from interface: Module

Starts the module. This will be called after init and getDependencies and signals that the module should now begin to perform whatever it was designed to do. This method call however should not block for long, so any time consuming tasks should be started in their own threads. You will typically get references to the required modules again in start using the findModule method of the manager and then store those references to instance variables for later use. You may throw a ModuleException if the module is not in a state where it can be started or it immediately becomes obvious that it cannot be started with the provided settings.

Specified by:

start in interface Module

Overrides:

start in class AbstractAction

Parameters:

manager - The module manager handling this module.

Throws:

ModuleException

stop

public void stop(ModuleManager manager)

Description copied from interface: Module

Stops the module. Should stop all threads used by the module, free any large data structures and perform other cleanup. It is possible that the module will be started again later with a start method call (and foregoing init and getDependencies calls). The module should be left in a state where this is possible.

Specified by:

stop in interface Module

Overrides:

stop in class AbstractAction

Parameters:

manager - The module manager handling this module.