Controller-hierarchy, best practise?
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
Hi Henk You should definitely have a read of this article. In summary, to minimise top level controller code and stop the lower level controllers treading on each others' toes, just let Plack do all the delegation work for you. http://advent.perldancer.org/2014/9 Andrew On Thu, Aug 6, 2015 at 12:08 PM, Henk van Tijen || <henkvantijen@gmail.com> wrote:
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 _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Andrew Solomon Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon
Am 06.08.15 um 13:08 schrieb Henk van Tijen ||: […]
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’ ?
With this, you'd create a new instance of MyDancer::Controller::FoobarController for *every* request, this is definitively 'ugh'. If your controller does not hold any state, you can skip the whole OO thing, and just call a sub in another package: use MyDancer::Controller::FoobarController; get '/Foobar/jump' => sub { MyDancer::Controller::FoobarController::jump(); }; Jochen
participants (3)
-
Andrew Solomon -
Henk van Tijen || -
Jochen Lutz