October 2015 - dancer-users - lists.preshweb.co.uk

Advent 2015, medium-scale Dancer, part 1: Perl Modules
by Warren Young 27 Oct '15

27 Oct '15

I’m going to post the article parts here as I finish the first draft of each, for public comment. I’ll do a polishing pass or two later, before these go up on the official site. This first part has an introduction section that won’t be repeated in later parts, because the parts are intended to be hyperlinked together. You might want to copy this text into a GUI Markdown editor, so the markup doesn’t distract you from the content. If you don’t have one, try StackEdit: https://stackedit.io/ It’s a modern online web app for editing and viewing Markdown text. Getting Beyond Small-Scale in Dancer Application Design ======== When you generate a Dancer app with `dancer2 -a App`, you get a very nicely structured and useful starting point. As long as your app remains fairly small, you can work with this structure as-is clear through to completion. In that sense, the generated app is production-ready. The problem comes when you start getting to thousands of lines of Perl code, dozens of view files, and hundreds of routes, stretching the stock app design beyond its natural limits. This series of articles gives you one way to extend beyond this base. I say "one way" because Dancer is a policy-free web application framework. That means it purposely does not make whole classes of design decisions for you. It is up to you to use the toolset Dancer provides as you see fit. The design presented here is working quite well for us, so we think it is worthy of emulation, but we do not expect that it will for for all medium-scale web applications. Think of it more as a collection of design ideas, rather than a prescription of the One True Way to design a Dancer application. Part 1: Perl Modules --------- If you say `dancer2 -a App` at the command line, you get a few dozen files, only one of which is interesting for the purposes of this article. We're setting `bin/app.psgi` and `public/dispatch.*` aside as "uninteresting" here because we recommend that you leave these files as-is. None of your app-specific Perl code should go in these files. We're also ignoring `Makefile.PL`, since that isn't part of the app proper. That only leaves `lib/App.pm`. For small-scale apps, simply piling all of your Dancer-related app code into this file is just fine. Up to about one or two thousand lines of code, you can just use it as-is, for the same reason that a thousand-line monolithic Perl script is fine in other contexts, too. One of the nicest things about Dancer is that the `App/lib` directory is automatically added to the Perl module path. That leads to an obvious solution to the problem of too much code in a single file: break it out into other `*.pm` files in the `lib` directory. But how, exactly? I recommend following the example of CPAN, with a structure like the following: lib/App.pm # your app's main module lib/App/MajorFeature.pm # implementation of a major app feature lib/App/OtherFeature.pm # as many feature impl files as you need lib/App/API.pm # if your app has a REST API, put it here lib/App/Const.pm # maybe you have some app-wide constants lib/App/Utility.pm # every big app has a "junk drawer" module Then in `lib/App.pm`, you `use` all of these modules: use App::MajorFeature; use App::OtherFeature; use App::API; use App::Const; use App::Utility; How you design these modules is up to you. Standard [good Perl application design principles](http://stackoverflow.com/questions/410359/how-can-i-learn-to-wr… apply. There is one Dancer2-specific thing to beware of here, though: you must [set the `appname` property on the sub-modules](http://advent.perldancer.org/2014/10). If you don't, each sub-module will be considered a separate Dancer2 application, which puts unwanted barriers between the modules. (Dancer1 didn't have this restriction, because it was all just one global app.) The only Perl code remaining in `lib/App.pm` will be application initialization code, to be run once during app startup. (This, by the way, is why we don't need to modify `bin/app.psgi`: since it pretty much just loads Dancer and then calls `lib/App.pm`, there is no point to splitting app initialization code across the two files. Let `bin/app.psgi` remain a tiny little glue file to make PSGI happy.) Having done all this, about all that's left in `lib/App.pm` are the route definitions, which are the subject of the next article in this series.

1 0

Call to all Dancer2 plugin writers
by Yanick Champoux 26 Oct '15

26 Oct '15

Hi all, Underneath the surface, I've been toiling away at a new plugin system for Dancer2. This new system aims at fixing a few of the thorny issues of the current one, and add a wee bit of unicorn dust to the mix. ## For plugin users, the changes are: * No change! The new plugins will be called the same way as the old ones -- it'll be transparent to you if a plugin is new gen or old gen. Isn't that music to your ears, or what? :-) * No change! Plugins using the new system can work side-by-side with original plugins. It's all really transparent to you. Relax, we're taking care of everything. :-) ## For plugin writers, the changes are: * The new system inherit from Dancer2::Plugin2 (yes, I know, we just loooove that '2' digit around here...). * The new system is much more OO-based, which so far makes for cleaner, easier to write plugins. * The new system doesn't export the Dancer keywords into the plugin namespace. It removes a little bit of the sugar (you'll have to do `$self->app->request` instead of `request()` inside the plugin module), but it makes much more explicit what is the plugin class, and what is the plugin instance associated with an app. * Plugin can now use other plugins! * The list of plugin instances are also kept as an attribute in the app object, which makes introspection possible (a plugin, for example, can check if other plugin A is already loaded or not and do things in consequence). ## What do I want from you? Before unleashing D2::P2, it needs to be tested. Racke already migrated two of his plugins to D2::P2 (https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2) I would like for all of you to try to migrate your plugins, and report if it was a success, or if you uncovered some sore points. How to do that? I'm glad you asked: 1. clone and use the Dancer2 branch at https://github.com/yanick/Dancer2/tree/plugins-yanick 2. read the D2::P2 docs (`perldoc lib/Dancer2/Plugin2`) 3. if docs are not sufficient, check examples (`/t/plugins2-*`) and the already-ported modules at bullet #5 below. 4. report all problems, head-scratchers, suggestions, etc to https://github.com/PerlDancer/Dancer2/pull/1010#issuecomment-147376270 5. you ported the plugin and all works? Post your victory to the PR dicussion at #4, and add your plugin to the list at https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2 (that's important, I'll set up a job to test any new tweaks on D2::P2 to all the converted modules) And, of course, you have questions or anything, please feel free to hit me with'em. Joy, `/anick

3 10

New Dancer2 release en route to CPAN: 0.163000 and new core dev!
by Sawyer X 26 Oct '15

26 Oct '15

Here is the email for the latest release! I sent this to the wrong mailing list so no one saw it. Sorry about that. >>> Hi everyone, We have another great Dancer2 release hitting CPAN as we speak. This time with an announcement on a new core dev joining the Dancer team: Jason Crome. Please give him a warm welcome! We're very happy to have him join us and help make Dancer2 more approachable and welcoming to new-comers. We're very excited about this release as it carries some great changes and new features. **Fixed** * Internal errors do not accidentally trigger a 404. * Removing intermediate warnings between plugin systems transition. **Enhancements** * New keywords: "route_parameters", "request_parameters", and "body_parameters". These are considered safer and more comfortable than "param" or "params". We hope everyone switch to them instead. Try them out! * Delayed responses now have "on_error" providing a handler for errors when you have a streaming handler error. These should work on all event loops and isn't tied to a specific one. * Dancer2 command line utility "dancer2" now accepts "-s" for a skeleton directory so you can provide your own skeletons. * You can now use Dancer2 with the ":nopragmas" flag to prevent Dancer2 importing any pragmas into your namespace. * We now warn when you create a route parameter called "captures" or "splat", since it can conflict. **Documentation** * Fix instructions on running app.psgi files. * Add beginner-friendly application running. * Expanding on auto-reloading features in Plack. I want to thank everyone involved in this release and to the Dancer community. Have a great dance, :) Sawyer and the Dancer Core Dev Team.

2 1

Re: [dancer-users] articles for doco
by Rick Leir 26 Oct '15

26 Oct '15

On Mon, Oct 26, 2015 at 8:00 AM, <dancer-users-request(a)dancer.pm> wrote: > > Google Analytics of http://advent.perldancer.org/ tells me that most of > the > month the site gets about 1500-1800 visits / month > In December 2013 it got 3500 visits, in December 2014 it got 4,400 visits. > The http://perldancer.org/ site gets about 7-8,000 visits / month. > The perldancer hits include people who are curious and stay for less than a minute. The Advent hits might be more important, with people needing deep understanding, and thinking about the content (or not!). I suspect that hit counts do not tell us much. Do you know how long people stay on an Advent page? How many are referred from Google vs someones blog vs organic (bookmarks, or the address bar)? Yes, we need better doco at all levels: intro, reference, advanced usage. The Advent concept works great for intro and beyond. And writers might be more motivated to do an Advent article, rather than adding to Pod Manuals. Cheers Rick

2 1

Form Validation Profantity
by Richard Reina 25 Oct '15

25 Oct '15

I am still working on form validation and figure I need to check for profanity in case some prankster wants to get cute with a form. Was looking at Regexp::Common::profanity but wondering how other dancer programmers have handled this in their own projects. Thanks P.S. I know that some are of the mind that filtering for profanity is not worth the effort. I respect that opinion but still want to try.

2 2

Re: [dancer-users] PONAPI
by Rick Leir 22 Oct '15

22 Oct '15

On Thu, Oct 22, 2015 at 7:00 AM, <dancer-users-request(a)dancer.pm> wrote: > Mickey Nasriachi from > booking.com introduced the audience to PONAPI. PONAPI is a Perl > implementation of the JSON-API spec > Google did not help me with this. Where is there info about this? And I sense the need for a plugin.. Thanks Rick

2 1

Authentication Question
by Richard Reina 22 Oct '15

22 Oct '15

2015-10-21 19:02 GMT-05:00 Richard Reina <gatorreina(a)gmail.com>: > Oops let me try again. So far in my app I have been restricting access to > registered users that have created an account by doing: > > get '/dashboard' => sub { > > if (! defined(session 'username')) { > > redirect '/'; } > > } > > Is this okay? I really don't have any special roles to authenicate just > need to make sure that registered users only get to certain pages -- pages > that would only make sence if you were a registered user in the first > place. Can I forgoe more formal and extensive authentication in my case? > > 2015-10-21 19:00 GMT-05:00 Richard Reina <gatorreina(a)gmail.com>: > >> So far in my app I have been restricting access to registered users that >> have created an account by doing: >> >> get '/dashboard' => sub { >> if (! defined(session 'username')) { redirect '/'; } } Is >> this okay? I really don't have any special roles >> to authenicate just need to make >> sure that registered users only get to certain >> pages -- pages that would only make >> sence if you were a registered user in the first >> place. Can I forgoe more formal >> and extensive authentication in my case? >> >> > > _______________________________________________ > dancer-users mailing list > dancer-users(a)dancer.pm > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users > >

3 3

First day of the Perl Dancer Conference
by Stefan Hornburg (Racke) 22 Oct '15

22 Oct '15

The first day of the Perl Dancer conference summed up by Gert van der Spoel: Day one of the Perl Dancer conference has come to an end. A long day with a many great talks, good food and beer! The conference room at Schani hotel was packed when Stefan (racke) kicked off the conference with a short welcome, after which Sawyer X gave an inspiring talk about the current state of Dancer 2. Very good statistics show that there is an active user base not afraid to create pull requests and fork the project. Further good news about a couple of new features brought the conference to a positive start. Next up, Thomas Klausner added a game to his talk, where each received a 'bingo' card with terms used in his talk about OAuth2, API's and Microservices. It didn't take long before the win was claimed with a loud 'Bullshit!' as tradition prescribes. The talk focused on the mess that large system can become and provided some real life examples on how things could be alleviated. Peter Rabbitson took the audience on a journey through DBIx::Class. While the resulting SQL queries were growing more complex by the minute, the actual Perl code needed to create these queries kept being readable. The advice that existing applications could gradually integrate DBIx::Class, without the need to rewrite complete applications, was met with positive responses. Last before lunch, Andrew Beverly from Ctrl-O gave a hands-on demonstration of the use of Plugin::Auth::Extensible. Using the DBIC provider, he quickly whipped up user authentication and roles based authorization. A plugin of value for Perl projects in need of any kind of authentication. After a, slightly longer than expected, lunch break, Mickey Nasriachi from booking.com introduced the audience to PONAPI. PONAPI is a Perl implementation of the JSON-API spec which enables developers to build REST-API based projects without the redundant discussion about the exchange of information between clients and servers. That lunch had made the group sharp and full of attention was shown through some quite good questions about the handling of sorting and limiting resultsets. Next Gert van der Spoel took the stage, picking up the OAuth2 baton from Thomas, but going more in depth with regard to implementation and implications for use of Social Logins in ecommerce environments. Especially for the conference he wrote extensions to Dancer and Dancer2 Oauth plugins to work with the wyngle.com Social Login provider. Šimun Kodžoman brought the attention to Meteor, an environment for building modern web applications in pure JavaScript, and Materialize, a modern responsive front-end framework which, combined with a Dancer backend, resulted in a state of the art mobile application. In his talk he explained the reasons for the choices made for the combination of Materialize-Meteor-Dancer and it now will need to prove itself in a production environment. The final talk of the day came from one of the long distance travelers to the conference, Sam Batschelet. Starting with some simple, descriptive slides about containers, he shocked the audience with the schematics of a SpaceCamps setup. But after going into each part of the ecosystem, he managed to bring the shock level to acceptable heights. He showed he had done his research and was well prepared answering each question that followed his talk. The official part of the first conference day concluded with a panel discussion. A panel consisting of Dancer(2) core developers Russell Jenkins, Mickey Nasriachi, Alexis Sukrieh, Sawyer X and Stefan Hornburg sat down and had the attendees fire off questions and remarks about various topics related to Dancer 2. Within an hour after the panel discussion the first results were checked into feature branches of Dancer 2 forks, a clear sign that putting the brilliant minds of Dancer(2) together in one place is worth it! After the fruitful first conference day, a large group of conference attendees met up at Deewan to enjoy some good Pakistani food, complemented with big, cool beers, brushing up the vocal chords for conversations, discussions and fun until the late hours. -- Perl and Dancer Development Visit our Perl::Dancer conference 2015. More information on https://www.perl.dance.

1 0

(no subject)
by Richard Reina 22 Oct '15

22 Oct '15

So far in my app I have been restricting access to registered users that have created an account by doing: get '/dashboard' => sub { if (! defined(session 'username')) { redirect '/'; } } Is this okay? I really don't have any special roles to authenicate just need to make sure that registered users only get to certain pages -- pages that would only make sence if you were a registered user in the first place. Can I forgoe more formal and extensive authentication in my case?

1 1

Getting param name of dynamically named <input> tag
by Richard Reina 21 Oct '15

21 Oct '15

I have a input tag in a form: <div class="col-xs-4 col-md-4"> <div id="p_scents"> <p> <label for="p_scnts"><input type="text" id="p_scnt" size="20" name="p_scnt" value="" placeholder="email address" /></label> </p> </div> </div> Which gets it's name from the JS function below. However, that name I can't figure out. I have tried p_scnt_1 but it comes back undefined. Any ideas what the param name would be for each sequentially added item? Here's a working example of the form: http://jsfiddle.net/jaredwilli/tzpg4/4/ $(function() { var scntDiv = $('#p_scents'); var i = $('#p_scents p').size() + 1; $('#addScnt').live('click', function() { $('<p><label for="p_scnts"><input type="text" id="p_scnt" size="20" name="p_scnt_' + i +'" value="" placeholder="Input Value" /></label> <a href="#" id="remScnt">Remove</a></p>').appendTo(scntDiv); i++; return false; }); $('#remScnt').live('click', function() { if( i > 2 ) { $(this).parents('p').remove(); i--; } return false; }); });

4 7