Interceptors provide a means to encapsulate cross-cutting code that is executed on pre-defined points in the line of execution. Interceptors are classes that implement one or more interfaces from the package 'nl.openedge.baritus.interceptors'.

Interceptors can be used to decorate the normal execution. Also, by throwing FlowExceptions, interceptors can alter the flow of execution. An interceptor can throw a FlowException if it wants Baritus to stop normal processing and go to the given declared view (using ReturnNowFlowException) such as 'error', or dispatch to an arbitrary - non declared - URL (using DispatchNowFlowException) location.

The following interceptors are available.

An interceptor can alter the line of execution by thowing a FlowException. An example of when to do this is: if you expect a session variable to be set, but there is none, you might want to redirect to a search page or an error page. Another example: on certain non handled exceptions that are thrown in the perform method, you might want to redirect to a specific error page that is different from the error page that is shown when population errors occured.

There are two types of FlowExceptions that can be thrown by interceptors.

Finally, with FlowException property 'executeOtherInterceptors' you can set on the exception that indicates whether (some of the) other interceptors should be executed. FlowExceptions thrown by these interceptors are ignored.

Here is an example of how to use interceptors. In part of our imaginary application, we want to be sure that an object was saved in the session, and after we checked it is, we want to set that object as one of our form bean properties. If our object is not found however, we want to cancel the normal Baritus behaviour and do a redirect (or actually dispatch) to another location right away. Because we set that object in the form bean just before population takes place (but after the makeFormBean method was called), it can be populated by the request paremeters etc. as well.

First, there is our Interceptor.

public class LoadFooFromSessionInterceptor implements BeforePopulationInterceptor {

    /**
     * Before population takes place, we get our Foo object from the session, check
     * it's actually there (is not null) and set it in our form, so that it can be
     * populated as well.
     */
    public void doBeforePopulation(
        ControllerContext cctx, FormBeanContext formBeanContext)
        throws ServletException, DispatchNowFlowException, ReturnNowFlowException 
    {
        HttpServletRequest request = cctx.getRequest();
        HttpSession session = request.getSession();
        Foo ourFoo = (Foo) session.getAttribute(Constants.SESSION_KEY_FOO_OBJECT);

        if (ourFoo == null) 
        { // ourFoo does not exist in the session... redirect to 'home.m'
            throw new DispatchNowFlowException("home.m");
        } 
        else 
        { //  we're ok, set in form and exit method normally
            FooBarForm form = (FooBarForm) formBeanContext.getBean();
            form.setFoo(ourFoo);
        }
    }
}

Then, we should register the interceptor in the controllers we want to use it.

    public void init(Element controllerNode) throws ConfigException 
    {
        addInterceptor(new LoadFooFromSessionInterceptor());
    }

Baritus will now call this interceptor each time this control is used right after calling makeFormBean and just before population and validation takes place.

Just like you can do with validators, you can stack interceptors as well.

    public void init(Element controllerNode) throws ConfigException 
    {
        addInterceptor(new FooInterceptor());
        addInterceptor(new BarInterceptor());
        addInterceptor(new MooInterceptor());
    }

In the above example, all interceptors can be of the same type(s), and will be called in order of registration. Thus, FooInterceptor is called first, BarInterceptor after that and MooInterceptor is called last.