Intercepting Filter


Seagull uses the Intercepting Filter pattern which allows developers to setup a custom chain of pre and post processing filters on a per request basis.

As the data model is built up, it passes through the filter chain before reaching its ultimate target, the so-called Core Processor, which in most cases is the Application Controller. What this means is you can filter and transform any data coming into your core business process, then filter the results that are returned before they are sent back to the client.

Typically data being sent to the core business process is the request object. In Seagull's case this is also true, however data deemed valid from the request is mapped to an input object which is passed through the filter chain. After the target process has executed, a response in the form of an output object is sent back through the filter chain for post processing, and to eventually be returned to the client.

Here's an example to clarify:

            //  pre-process on $input
                // core process
            // post process on $output
    echo $output->data;

Note the inverted pyramid, more clearly described in this UML:

Customising the Filter Chain

Quite understandably the developer may want to customise the filters on a per-request basis. You may want to

  • output your data as XML
  • run it through an HTML to PDF converter

A generic filter chain is provided in Seagull by default, but is very easy to customise with one line of configuration.

In a module's config, add something like the following to setup your own chain, this example is for building a REST server:

requiresAuth    = false
filterChain     = " SGL_Task_Init,

Note that the target, in this case EG_CoreProcessor, must always be the last item in the list.

Make your Filters Portable

To build your own filter chain follow the example in /branches/0.6-bugfix/lib/SGL/FrontController.php. Here are some guidelines to keep your code clean and reusable: If you are using libs specific to your own project, for example "My Important Client", create your own namespaced lib directory somewhere on the filesystem, within Seagull if you like, eg:


and place your filters in an obvious place:


Add the path to this directory to your Seagull configuration, in Configuration -> General.

Finally, modify your module's conf.ini file to reflect the filters' class names and correct order:

requiresAuth    = false
filterChain     = " SGL_Task_Init,

The Filter chain object is the one that does the dynamic evaluation of your filter chain.

Where is this used in Seagull

Currently the export module uses the custom filter chain approach to set configurable headers, in this case the text/html Content-type headers, to produce an RSS feed. See the conf.ini for that module to get an idea for how few tasks are loaded, and how the ordering is important.

How Other Frameworks Intercept Requests

I've just been reading up on Django, probably the top-rated Python web framework right now, seems they haven't heard of intercepting filters, view their solution here:

I do like some of the filters they reference, would be nice to see in Seagull.

See Also