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

Dancer2::Plugin::Database side effects?
by Mike Cu 07 Nov '15

07 Nov '15

I've replaced all my $dbh = DBI->connect, $sth = $dbh->prepare calls with the Dancer2::Plugin::Database equivalents Before that, when there was interaction with the UI, I would explicitly connect, run all my sql and then disconnect, on every Ajax call . After I switched to Dancer2::Plugin::Database,I have to do the same interaction, for example, clicking a button which invokes an Ajax call which in turn calls the database retrieving the new data and updates the UI, does not have an immediate effect ,the UI is not being updated. So I have to do the same move (click a second time) for getting the desirable outcome Has that something to do with caching and reusing the connection?

4 6

Perl Dancer Rewrite url
by Hugues 03 Nov '15

03 Nov '15

Hello I use perl dancer with Apache in mod_proxy + starman.pl ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/ I've got path like /website/about /website/contact etc..; for www.mydomain.com I would like to rewrite url /about /contat etc.. I try with RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P] but result is no good, I go to /.... if someone has a idea ? Thanks Hugues.

9 16

Help us write and publish the official PerlDancer Book!
by Alexis Sukrieh 03 Nov '15

03 Nov '15

Dear fellow PerlDancer users, developers and friends. It's been a long time since we decided to start working on a book. Different attempts were made, by different core developers, and because of many reasons, we still don't have our official book finished. We have a big plan in mind. Writing a comprehensive book that will go from the very beginning of the project's philosophy to the deepest secrets of the framework. A book any PerlDancer fan would love to have. We know what needs to be written, but we need help. One of the main reason we don't have a book yet is the lack of time and focus, and the fact that hacking the code gets always a higher priority than focusing on a long-term brain-marathon such as writing a book. But. We want this book. You want this book. It HAS TO BE :) So during the Perl Dancer 2015 conference, we chatted a bit about that, and had an idea. What about making that project a real priority, and what about trying to raise some money to give us time, group efforts, and resources to print it? Well, we did that. We launched a Kickstarter campaign to raise some funds for buying us time and letting us print the book, it's here: https://www.kickstarter.com/projects/1856511822/perldancer-book Please. If you use PerlDancer at work, speak about it to your boss, and ask about the opportunity to support the project, you'll get a printed copy of the book in the end. If you use PerlDancer for personal use, consider supporting us even with a small contribution, 5 or 10 euros can make a difference if everyone in this list contributes. In the end, when this book will be real and printed it'll be a major asset for all of us, PerlDancer users, and it will help make the project shine even more. If you like Dancer, contribute, and spread the word, share this link everywhere! :) Let's do this. Alexis, for the core team. -- Alexis Sukrieh http://twitter.com/sukria - http://blog.sukria.net "*Believe it or not, I can actually draw.*" -- Jean-Michel Basquiat

5 5

Perl Dancer Conference 2015 Writeup
by Ben Witten 01 Nov '15

01 Nov '15

Hi all, I wanted to share End Point’s first blog post on the Perl Dancer Conference 2015: http://blog.endpoint.com/2015/10/perl-dancer-conference-2015-report.html <http://blog.endpoint.com/2015/10/perl-dancer-conference-2015-report.html> Ben Witten O: 212.929.6923 | C: 301.801.9088 304 Park Avenue S, Suite 214 New York, NY 10010 bwitten(a)endpoint.com <mailto:bwitten@endpoint.com> | www.endpoint.com <http://www.endpoint.com/>

2 1

Dancer Advent Calendar 2015
by Sawyer X 01 Nov '15

01 Nov '15

Hi everyone! Last year we've ran the Dancer Advent Calendar 2014[1] containing 24 articles on how to use Dancer2, what it can do, what features it has, etc., which was very successful. We would like to have another Dancer Advent Calendar this year. This means 24 more articles. We need *you*. I'm collecting articles on topics ranging from: * Something you do in Dancer (a trick you have, a suggestion on how to use it). * Projects you made that use Dancer. * Plugins you like, plugins you wrote. * Topics I haven't thought of! The Github project for the Advent Calendar is: https://github.com/PerlDancer/advent-calendar Please feel free to submit pull requests with your articles, open issues and email back to the list (or to me) your suggestions. Anything goes. Let's have another set of great articles showing off what we have and what we can do. Thanks, Sawyer. [1] advent.perldancer.org/2014

7 21

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