Thank you very much for this. I found these articles very helpful. Do you have any suggestions or design patterns for including commonly used modules? For example, how may I reduce the following without repeating myself? MyApp::Module1.pm use Dancer2; use Dancer2 appname => ‘myapp’; use Dancer2::Plugin::Ajax; MyApp::Module2.pm use Dancer2; use Dancer2 appname => ‘myapp’; use Dancer2::Plugin::Ajax; -Bill Carr
On Dec 23, 2015, at 3:49 AM, Warren Young <wyml@etr-usa.com> wrote:
I’ve just finished a touch-up pass on my series of articles on getting beyond the initial small-scale app design generated by “dancer -a app”. They were to be part of the 2015 advent calendar, but for now, here are the current links:
Part 1, modules: https://goo.gl/SFn30N Part 2, routes: https://goo.gl/UfMqGo Part 3, views: https://goo.gl/DN8xYO Part 4, front end: https://goo.gl/wlyOFB Part 5, REST API: https://goo.gl/VbMI4P Part 6, reloader: https://goo.gl/6AiiIm
(These are GitHub links, showing the current tip-of-master versions, shortened so they don’t break due to line wrapping.)
The major change is that I’ve replaced the context object idea with direct Dancer DSL calls. I had poor justifications for this object, which I realized after watching Alexis Sukrieh’s 2015 conference video.
That in turn allowed me to drop a level of function calls, which makes the recommended design considerably cleaner.
I’ve also fixed up some UTF-8 problems, so you don’t get broken Latin-1 characters when viewing the articles in a web browser. (They look fine on a UTF-8 terminal. :) ) _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users