Hello dear esteemed monks,

After announcing my toy web framework to a local Perl mongers group, I received a request from fellow monger to add filters. He was citing sinatra.rb as reference. I promptly found both Mojolicious and Dancer to have similar functionality called hooks. Apache/mod_perl allows to hook into different stages of request processing as well, and I was planning to do something like that as well.

So I set myself on a quest to add hooks. However, the very first attempts turned out to be utterly over-engineered (almost everything I do is, see Implementing methods in a subclass or providing in-place callback: Is it overengineered?). It's easy to make a mistake, and it would be hard to correct it later.

Some background: the framework goes as follows:

use strict;
use warnings;
use MVC::Neaf;

MVC::Neaf->route( '/some/uri/path' => sub {
    my $request = shift;
    # ... query request object for params, cookies, etc

    # a valid way to return configurable error page
    die 403 if $perm_denied;

    # result will be fed to View's render() method
    # the user-agent will get a 200 page with some headers
    #     and rendered content
    return \%hash; 
}, view => 'TT');

# more handlers

MVC::Neaf->run;
# end of the application (as in PSGI or Dancer)
[download]

What I clearly want:

• Defining hooks in form of pair<path, stage> => sub { my $request = shift; # .... };
• Hooks for ALL paths prefixing the URI path being executed in order
• Multiple hooks can be added for the same path (we'll have to stack them anyway)

What I'm unsure about:

• What the stages are? I see at least pre-route, pre-handler, pre-respond and post-cleanup, but maybe there are more. There's a clear gap between handler and rendering to put a hook as well.
• How to share state between handlers? It looks like I'll need some per-request data storage.

So before I proceed to answering these questions I would like to ask for example usage of this feature. Here's what I can think of:

• Authorisation - checking a user is authorized to access certain part of the website (or is logged in at all to begin with).
• Fetching an entity - if separate GET/POST/PUT/PATCH handlers are set up for the same URI, load what they operate on before proceeding. I don't like the idea, but I can't forbid others to do so.
• Gathering site response time stats - currently hardwired into the module's core, want to split it out anyway.
• Cleaning up stuff - Neaf has built-in $request->postpone(sub { ... }); functionality, but maybe this can be generalized.
• Handling language/country setup - via cookies, geoIP etc.

What else did you encounter / think about doing via such hooks in real-life applications? Thank you.