Medium-Scale Dancer series updated
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. :) )
This is awesome, Warren! I can probably give an entire talk or a series of articles on why the context object was problematic and why it was useful. Mickey and I spent over 4 full days of hacking to completely remove the context object[1]. It was 48 separate commits! I'll read the articles as soon as I can (hopefully tomorrow morning) and give any comments. Very happy to see it. Thanks for the work! :) [1] https://github.com/PerlDancer/Dancer2/commit/e0772f9 On Wed, Dec 23, 2015 at 9: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
On Dec 26, 2015, at 3:01 AM, Sawyer X <xsawyerx@gmail.com> wrote:
This is awesome, Warren!
Glad to hear it. It’s too bad the advent project fizzled this year. Maybe you’ll pull them into next year’s calendar.
I can probably give an entire talk or a series of articles on why the context object was problematic and why it was useful. Mickey and I spent over 4 full days of hacking to completely remove the context object[1]. It was 48 separate commits!
My context() function isn’t the same thing as the D2 Context object. This article series is a distillation of experience with a D1 app, translated post hoc into D2 code. I evaluated D2 about a year and a half ago, rejecting it because I couldn’t get something working right. (I don’t remember what it was.) I remember deciding to provide a thin mimicry of D2’s old Context object in our D1 code. Replacing context() in our app with direct DSL calls dropped 400 SLOC, so I guess it wasn’t such a good idea after all. :)
This is really fantastic -- thank you Warren. I am trying to persuade my coworkers to switch to Dancer, and this article series will be a huge help in demonstrating how to design and build a large application. Thank you! 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
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
A couple of nice modules that make it easy to create sets of commonly-used modules: Import::Base, https://metacpan.org/pod/Import::Base Import::Into, https://metacpan.org/pod/Import::Into There's also a list of modules with similar functionality in the docs for Import::Base. On 28 December 2015 at 16:38, William Carr <bill@bottlenose-wine.com> wrote:
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
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Dec 28, 2015, at 9:38 AM, William Carr <bill@bottlenose-wine.com> wrote:
how may I reduce the following without repeating myself?
MyApp::Module1.pm use Dancer2; use Dancer2 appname => ‘myapp’;
You only need the second “use” call. Setting the appname property is not a separate thing from importing Dancer2.
use Dancer2::Plugin::Ajax;
MyApp::Module2.pm use Dancer2; use Dancer2 appname => ‘myapp’; use Dancer2::Plugin::Ajax;
Move “use Dancer2::Plugin::Ajax;” to lib/App.pm, before the “use” calls to your other app modules. Then anything that module exports to the global namespace will be available to those modules. By carefully ordering your “use” statements, you can usually find a way to mention any given module only once. There are even cases where doing so is *required*. For example, if you say something like: use List::Util qw(min max); from two different modules, and “use” both of those from a third module, you’ll get a complaint about redefined min/max. The fix is to move that “use” call to a single central location that everyone that needs those utility functions depends on.
participants (4)
-
Amelia Ireland -
Sawyer X -
Warren Young -
William Carr