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

Fwd: Project Update #1: PerlDancer Book by sukria@gmail.com
by Alexis Sukrieh 01 Nov '15

01 Nov '15

FYI. Thanks to our early backers! ---------- Forwarded message ---------- From: Kickstarter <no-reply(a)kickstarter.com> Date: 2015-11-01 14:12 GMT+01:00 Subject: Project Update #1: PerlDancer Book by sukria(a)gmail.com To: sukria(a)gmail.com Here’s a copy of your most recent project update! Just a reminder that you have 30 minutes from the time an update is posted to edit it. [image: Kickstarter] <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> 1 1000 reached in less than 24 hours! <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> Posted by sukria(a)gmail.com I'm super glad to send this first udpate: we reached 1000 euros in our first day! That is awesome! Thanks a lot to Wendy, who backed the project to make us reach that bar, that is very nice! The team is now officially exposed on our PerlDancer organization, under the name "PerlDancer Book Authors", you can see it here <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> . We're in the process of defining the big plan of the book, we have decided to go with an e-commerce application, that will get built step by step, iteratively, as we go over chapters, the app will get more and more features. This will give enough business-logic to cover all the main features of Dancer2 (and yes, it will be a Dancer2 book, as Dancer1 is now frozen). We are also studying all the possible options for publishing costs, in order to decide how we'll get the book printed. Making this campaign a success would definitely help us to pick the best option to get the book printed in good conditions. Again, thanks a lot all our early backers, you guys rock. Check out also this blog post <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> which describes very well why we started this campaign. And don't forget to spread the news, again, and to share our KS page, time is running fast! Happy dancing. ------------------------------ [image: Heart red3x 3134f4a39cd7f811af060f497e853898881055b8524f3b5d8bc8bad4e7725de3] Like <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> Comment on Kickstarter <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> ------------------------------ Want to keep up with projects you love on the go? Try Kickstarter for iPhone and iPad! <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> Don't want to receive updates from this project? That's okay, you can unsubscribe. <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> ------------------------------ [image: Kickstarter on Facebook] <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> [image: Kickstarter on Facebook] <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> Kickstarter · 58 Kent St, Brooklyn NY 11222 · www.kickstarter.com <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> Contact Us <https://emails.kickstarter.com/mpss/c/3wA/6TYCAA/t.1rr/IxBHZwJCT3SfOEhXW-C4…> -- Alexis Sukrieh http://twitter.com/sukria - http://blog.sukria.net "*Believe it or not, I can actually draw.*" -- Jean-Michel Basquiat

1 0

Dancer2::Plugin::SendAs
by Russell Jenkins 28 Oct '15

28 Oct '15

Fellow Dancers, At the Dancer conference in Vienna last week, Dancer2::Plugin::SendAs was developed and released. This plugin makes it easy to return either serialized content or HTML from a route. Here's the synopsis: use Dancer2; use Dancer2::Plugin::SendAs; set serializer => 'YAML'; set template => 'template_toolkit'; # returns HTML content, though YAML serializer is configured get '/html' => sub { send_as html => template 'foo'; }; # returns JSON content, even with YAML serializer configured get '/json/**' => sub { send_as json => splat; # JSON, not YAML! }; Sawyer and I briefly discussed if this should be core functionality during the conference. We decided to release it as a plugin and review moving it to core if other Dancers find this functionality useful. Grab it from CPAN and give it a workout [1]. If send_as solves an issue for your apps or makes your code simpler, let us know (responding here if fine). If there is enough [2] feedback that this is generally useful, we'll make it core functionality. Happy dancing! Russell. [1] I'm doing some post-conference travel, so haven't used it in anger myself yet. [2] Don't ask me to quantify "enough" ;)

7 6

Advent 2015, medium-scale Dancer, part 2: Route Definitions
by Warren Young 28 Oct '15

28 Oct '15

FYI: Don’t judge the code in the following article part too harshly. It’s all been written off-the-cuff. I have not yet tried to save it out into a final app and make sure it runs. That will be part of the polishing passes to come. The main thing I want comment on is the overall ideas presented, not the niggly details. I don’t mean that I do not welcome nit-picking, just that I prefer that you keep it brief. Yes, I realize that the code probably doesn’t work as-is yet, and yes, I realize that I probably have committed spelling and grammar mistakes. Kindly just point them out, without discussing how this pile of errors reflects on my ancestry. :) Part 2: Route Definitions ------------- By the time a Dancer app grows large enough that you want to start breaking it up into multiple Perl modules, as in the previous article in this series, you've probably also defined enough routes that you're starting to have problems managing them all. Just as with the Perl code, Dancer lets us break up the monolithic route definition set, too. If you structured your app in the way recommended in the first part of this series, each major feature of your web app is in its own Perl module. That Perl module's name likely corresponds to some part of your app's URL scheme. Let's say you're exposing the features of `App::MajorFeature` as `/mf` in URLs, with sub-features underneath that. If you extend the generated `lib/App.pm` file in the most obvious way, using the simplest examples from the Dancer documentation, you might have a mess that looks something like this: get '/mf' => sub { # Lots of Perl code to return the top-level MajorFeature view }; get '/mf/subfeature' => sub { # Implementation of a sub-feature of MajorFeature }; post '/mf/subfeature' => sub { # Maybe you need a way to add new subfeature objects }; put '/mf/subfeature' => sub { # And maybe also a way to edit existing subfeature objects }; del '/mf/subfeature/:id' => sub { # And a way to delete them, too }; The first thing to fix here is that almost all of the Perl code implementing each route handler should move to `lib/App/*.pm`. Ideally, each route handler body should do nothing more than call a function in one of these modules: get '/mf' => sub { App::MajorFeature::get(context); }; get '/mf/subfeature' => sub { App::MajorFeature::sub_feature(context); }; post '/mf/subfeature' => sub { App::MajorFeature::add(context); }; put '/mf/subfeature' => sub { App::MajorFeature::modify(context); }; del '/mf/subfeature/:id' => sub { App::MajorFeature::remove(context); }; The `context()` function is a small wrapper I define at global scope within the app: sub context { return { config => config(), request => request(), session => session(), conn => App::Utility::get_db_conn(), etc => ... }; } That is, it just bundles up a bunch of Dancer objects into a hash for you. I find this convenient, but perhaps you will want to use the DSL instead. The URL scheme defined above is quite redundant. We can factor out that redundancy in two stages. First, Dancer has the awesome [`prefix`](https://metacpan.org/pod/distribution/Dancer2/lib/Dancer2/Manual.pod#prefix) feature, which lets us express the URL hierarchy directly in the code, without repeating each element: prefix '/mf' => sub { get '/' => sub { App::MajorFeature::get(context); }; prefix '/subfeature' => sub { get '/' => sub { App::MajorFeature::sub_feature(context); }; post '/' => sub { App::MajorFeature::add(context); }; put '/' => sub { App::MajorFeature::modify(context); }; del '/:id' => sub { App::MajorFeature::remove(context); }; }; }; Factoring out the `/mf` part was a net loss of 1 character per route with our 4-space indents, but factoring out `/subfeature` saved us a net 6 characters per route, which really helps make the code easier to read. You may find after rewriting your URL handlers this way that you see structural patterns in the URLs that will lead you toward a better URL design. This can be especially helpful in REST API design, which we will discuss in a later part of this article series. But to get back to our refactoring work, a second excellent feature of Dancer lets us shorten those lines of code still further. So far, we've been using explicitly-qualified function names. This is because we want to use short function names within the modules (e.g. `Get()`) without causing namespace collisions by exporting all of the functions. But in fact, there is actually no need to expose the API of your modules outside the module itself. Dancer doesn't care *where* you define the route handlers, just that they're all defined by the time your caller wants to use them. In the previous part of this article series, we said `use App::MajorFeature` and such within `lib/App.pm`, so every one of our app's modules gets executed on startup. This means that any code at global scope within these modules also runs at startup. Therefore, we can move all of the route definitions above from `lib/App.pm` to the end of `lib/App/MajorFeature.pm`: prefix '/mf' => sub { get '/' => sub { get(context); }; prefix '/subfeature' => sub { get '/' => sub { sub_feature(context); }; post '/' => sub { add(context); }; put '/' => sub { modify(context); }; del '/:id' => sub { remove(context); }; }; }; Now all the function calls are made within the module itself, so we don't need to qualify them. If you are using my `context()` idea, you will have to move it out of `lib/App.pm`, such as into the `App::Utility` module, exported by default: package App::Utility { use Dancer2 appname => 'App'; require Exporter; use base qw(Exporter); our @EXPORT = qw(context); sub get_db_conn { # do something useful here; # not exported, since context->{conn} holds our return value } sub context { return { config => config(), request => request(), session => session(), conn => get_db_conn(), etc => ... }; } } In the first part of this article series, we moved almost all of the Perl code from `lib/App.pm` into a collection of tightly-scoped `lib/App/*.pm` modules. In this second part, we moved most of the route definitions into those modules, too, not only cleaning up `lib/App.pm`, but also shortening the definition of those route handlers considerably by removing redundant code. All that should be left in `lib/App.pm` is app-wide Dancer setup code, such has global hook definitions. In the next part, we will consider how this application restructuring affects the design of other parts of the web app.

2 2

Potential Job, Adelaide, South Australia
by David H 28 Oct '15

28 Oct '15

Hi All, There is the potential of a job coming up in Adelaide, South Australia (locally based) in the next couple of months if anyone is interested, please contact me. Must be able to be on-site so you will need to be located actually in Adelaide, South Australia or willing to travel here if you aren't already. We are looking for someone with Perl Dancer experience (hence why I'm writing to the list). The pay will be around the $AUD90,000 per year mark and the job will be a 3 month or 6 month contract. Thanks, David

1 0

Delayed template processing
by Joerg Fallmann 27 Oct '15

27 Oct '15

Hi Everyone, What I'm looking for is a way to render a template with part of the results to the user to see while I continue processing and when I'm done I want to show the final template with all results. I'm currently using the new delayed method, which works fine for strings, but if I want to render templates it does not provide content until the very end, so no in-between output is produced, as I would like to show. Example code here: |get '/test/:*?' => sub { my $id = params->{'id'}; my $blub = params->{'blub'}; delayed { my $tt = Template->new( {INCLUDE_PATH => "$path", WRAPPER => 'layout.tt', RELATIVE => 1, }) || die "Template error: $Template::ERROR\n"; $tt->process('view.tt', { 'id' => $id, 'bla' => $blub }; content $tt; ### Process further push my @more, "String"; my $tt2 = Template->new( {INCLUDE_PATH => "$path", WRAPPER => 'layout.tt', RELATIVE => 1, }) || die "Template error: $Template::ERROR\n"; $tt2->process('view.tt', { 'id' => $id, 'bla' => $blub, 'more' => \@more }; content $tt2; done; }; }; | Is this possible or am I completely on the wrong track? Thanks, Joerg Phone: +43 1 4277 52732

9 16

Re: [dancer-users] infinite scrolling
by Rick Leir 27 Oct '15

27 Oct '15

On Tue, Oct 27, 2015 at 8:00 AM, <dancer-users-request(a)dancer.pm> wrote: > > In 2015, you do it with endless scrolling: > > https://github.com/fredwu/jquery-endless-scroll > > Pagination is soooo 2001. > Thanks for bringing this up, there are many considerations: sorting, faceting ... http://ux.stackexchange.com/questions/12073/is-infinite-scrolling-justifiab… http://uxmovement.com/navigation/infinite-scrolling-best-practices/ http://ux.stackexchange.com/questions/48992/sorting-filtering-on-infinite-s… Cheers -- Rick

2 1

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