[dancer-users] Controller-hierarchy, best practise?

[Henk van Tijen ||]

Hi, perl programmer wannabee here;-)  Hope this question is suited for
this list.

In the examples of Dancer apps I've seen there are no separate
Controller classes. The sub() handlers of the routes act as a sort of
mini- controllers in the examples of the documentation. But as I am
starting on a project that would grow in size, I'd like use full
controllers classes, like for a dashboard view that pulls in data from
many data source.  Where do I fit the controller classes hierarchy
in?

I’ve found his article
http://fraley.de/2013/10/18/structuring-larger-dancer-applications/
that gives a starting point, the sample code is here
https://github.com/pwfraley/DancerPrelaunch

In the Fraley code, the idea of a central routes table is done away
with.  Instead, each controller defines its own routes it responds
too. Good de-coupling practice, I suppose. But I like the default
central MyDancer::App.pm package with a central routes table:
- For one, it gives me in a glance an overview of all routes, the
whole structure of the app.
- But even more, it allows for constructs like ‘pass’ to group routes,
conditionally skip routes (when not logged in or no session).
- It provides a central lookaction for ‘hooks’ , process params,
logging etc. (but a a base superclass Controller could be the place to
do that too).

On the examples of fraley.de , each controller has its own proper
routes defined, but how do you combine that with the generics
(loggedin, session, hooks, error) without repeating boiler plate code
in each controller?

To be more specific, I intend to structure my app along route definitions like:

use MyDancer::Controller::FoobarController;
get ‘/Foobar/jump’ => sub {
    my $fb = FoobarController->new;
    $fb->jump;
};

Is this okay or ‘ugh’  ?

Any more considerations or advice or pointers on how to organize a
Dancer2 app with controller classes are welcome!
~henk