On Thu, Jan 3, 2013 at 12:58 PM, Damien Krotkine <dkrotkine@gmail.com> wrote:
By default a hook would be package-scoped. But we should make it possible to scope it to the whole application ( if that's possible), and also be able to scope it to a selection of routes, as David Golden mentioned.
I wouldn't say that *all* hooks need to have scope of that sort. But a "before route" hook scoped to a route would seem to make sense. If you think about how, say, OX, does it. handlers dispatch to methods, and then you can use the normal Moose-ish before/after/around modifiers on those methods, which has some nice elegance. Since Dancer uses coderefs to dispatch, it would be useful to have a way to act before/after/around the dispatches. Some of the auth plugins do that by just wrapping the ref. E.g. get "/private/foo" => needs login => sub { ... }; The "problem" there is that you have to remember the auth modifier for every dispatch, plus if you want to have multiple modifiers, then you can get into this sort of chaining: get "/private/foo" => needs login => using another_thing => remember one_more => sub { ... }; That gets brittle and repetitive fast. I think the package scoped hooks can work. But it might also make sense to just have route modifiers. In the most general sense: around qr{^/private} => sub { my $coderef = shift; # ... do stuff before route ... my $result = $coderef->(); # ... do stuff after route ... return $result }; The question is whether that is/can-be dynamic or whether at the time the "around" is called, it goes and applies itself to every currently defined route that matches. It's probably hard to do "around" dynamically, but it might be possible to do "before" dynamically. (I.e. walk array of before route hooks, fire ones that match in order, then fire the handler.) In any case, these are the tricky design decisions to be made. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg