robfig/revel — pull request #151 by robfig (2013-05-18 17:24:44+00:00)
Title: Filters

Proof of concept for using the Filter architecture instead of the Plugin architecture.

Original message to mailing list copied below:

I've lately been looking at how Rails is put together, and I think I've become convinced that the Filter model is far superior to the Plugin model. In the filter model, the control flow goes through a sequence of nested Filters, each one that provides some aspect (e.g. Routing, Session support) and calls the next one in the chain. The sequence of filters can be configured for the application, controller, or action. This is in contrast to the Plugin model, which is basically a collection of hooks.

The filter model seems is much more flexible because:
* A filter entirely wraps the action invocation, so it gets hooks like BeforeRequest, AfterRequest, OnException, Finally triviallly. They are not at the mercy of the framework providing them the right hook.
* As an example, Play! has defined about 30 different hooks to handle all the cases that have come up, some with subtly different names like (beforeInvocation(), beforeActionInvocation()), or (onApplicationStart(), onApplicationReady(), afterApplicationStart()), or (onApplicationInvocationResult(), onInvocationSuccess(), afterInvocation())
* Additionally, idiosyncratic behaviors like "if a BeforeRequest returns a result, then the request returns immediately" is more natural, because the logic is in the filter, not implemented as a special case in the framework.
* Providing control over the filter stack on an application / controller / action level adds a lot of flexibility that would be a pain to add to Plugins.
* The framework code is better factored. It is already factored pretty well into plugins, but without adding many more hooks it is not possible to use a different router, etc, which is something Filters handle very easily.
* If J2EE uses it, it must be the best model :)

The one annoying thing is that it makes stack traces annoyingly deep, but that seems like a small price to pay.