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

Deploying a Dancer app with perlbrew under Apache
by Joel Roth 07 May '14

07 May '14

Hi list, Having struggled a while to get a Dancer app working with perlbrew on a shared host with the Apache webserver, I'm documenting it for others. Please let me know if you think it is useful, or have any suggestions. Joel -- Deploying a Dancer app with perlbrew under Apache I'll assume you've successfully installed perlbrew, so that (for example) typing perlbrew use 5.16.3; perl -v shows you the correct perl version. On my shared host, the requests are handled by a CGI script in the document root for the site called dispatch.cgi: #!/bin/sh source ~/.bashrc # you need this for the correct environment perlbrew use 5.16.3 # and this for the correct perl exec `dirname $0`/plack_runner.pl ${1+"$@"} I use mod-rewrite to prepend "dispatch.cgi" to the routes when required, thereby eliminating the name of the script from links to the site. The file .htaccess, in the document root, contains this code: # BEGIN dancer application htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule (.*) dispatch.cgi/$1 # END dancer application htaccess dispatch.cgi calls plack_runner.pl, also in the document root: #!/usr/bin/env perl use autodie; use Plack::Runner; chdir '/home/username/app_dir'; Plack::Runner->run('app.psgi'); plack_runner.pl runs app.psgi, which lives in the app_dir. #!/usr/bin/env perl BEGIN { push @ARGV, qw(--environment=production) } use lib ('/home/username/app_dir/lib'); use Dancer; load_app 'danceapp'; dance; To test the website locally on my laptop, I run app.psgi from the command line and point my browser at http://localhost:3000. (I use the same directory path for the app_dir on my laptop as on the production site.) To make several similar websites using the same app code, I converted danceapp.pm to a module and installed it conventionally using perlbrew and cpanm. perlbrew use 5.16.3 cpanm My-Dancer-App-0.1.tar.gz With the app implemented this way, the 'use lib' line in app.psgi is not required. (END)

7 13

Questions about distributing Dancer2 applications
by Maxwell Carey 06 May '14

06 May '14

I have a Dancer2 application that I'd like to distribute. I have a couple of questions about the process that may be more related to ExtUtils::MakeMaker than to Dancer, but I figured I'd ask here first since deployment of web applications seems a little different from installing regular modules. 1. Typically when you install a Perl package with perl Makefile.PL && make && make install modules goes somewhere like /usr/local/lib/perl5/, binaries go somewhere like /usr/local/bin/, documentation goes somewhere else, and so on. I don't want my application fragmented like that (and I don't think it would even work if it were); when users run `make install` I want everything from my MANIFEST to simply be copied into the install directory as-is. For example, I want to end up with /usr/local/myapp/bin/ /usr/local/myapp/lib/ /usr/local/myapp/lib/myapp.pm /usr/local/myapp/public/ ... I assume this is how most Dancer/Dancer2 apps would have to be installed to work properly...how can I do this? I tried perl Makefile.PL INSTALL_BASE=/usr/local/myapp/ but that puts myapp.pm in /usr/local/myapp/lib/perl5/ and doesn't copy any of the other files or directories I want, like public/. 2. My app includes an index page containing links to other pages on the same server, e.g. <a href="http://host.example.com/foo">foo</a> This page is served with send_file, no templates involved. So far I have simply hard-coded the server name into the file, but that won't work when somebody tries to install it on another server. I thought I could use the PL_FILES attribute to WriteMakefile() to run a script that fills in the correct host name during the build process. Would this be a reasonable approach?

2 2

dancer app feature: alternate templating system
by Warren Young 06 May '14

06 May '14

I've just been playing with the "dancer" command again to get someone else started with Dancer. This made me remember some difficulties I had getting started with Dancer myself. It would have been most useful to have a flag that lets you choose an alternate templating system. The files generated for TT require enough changes to make them work with other templating systems that unless you already know what the differences have to be, it's somewhat difficult to figure out where to start. Also, I noticed that the generated main.tt page hard-codes the paths to the app. It should use settings.appdir instead. You notice this when you copy the web app to another path and re-launch it.

1 0

Why do warnings cause Dancer to fail?
by Joel Roth 06 May '14

06 May '14

Is it a configuration thing? Perl usually lets *me* decide how warnings should be handled. Does Dancer allow it too? If it is a design decision, is there a theory behind this that is written up somewhere? kind regards, Joel -- Joel Roth

6 10

Flexible credentials with Dancer::Plugin::Database
by Lutz Gehlen 06 May '14

06 May '14

Hello all, I would like to use Dancer::Plugin::Database to access a postgresql database from my dancer application. The docu suggests to configure the connection like this: plugins: Database: driver: 'mysql' database: 'test' host: 'localhost' port: 3306 username: 'myusername' password: 'mypassword' connection_check_threshold: 10 dbi_params: RaiseError: 1 AutoCommit: 1 on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'" ] log_queries: 1 handle_class: 'My::Super::Sexy::Database::Handle' However, I would like to store the login details, namely username and password, in a different file that I can exclude from version control by gitignore for security reasons as well as to enable my co-developers to use different credentials on their system. Is there a good way to achieve this? Thanks for your help, Lutz

4 7

Doc bug: params() return value
by Warren Young 05 May '14

05 May '14

This page claims params() returns a hashref, always: https://metacpan.org/pod/Dancer::Request#params Not true. It only does so in scalar context. Thus: myfunction(params); will pass myfunction a hash which gets flattened to an array, not a hashref. The fix is myfunction(scalar params); Also, this link from that section: https://metacpan.org/pod/Dancer::Request#params-source is missing the "-source" bit at the end. (The latter link does document this behavior of params(), but that didn't stop me from banging my head against a wall for an hour or two while I still believed what the first page said.)

3 4

Major Dancer 2 release: 0.140000
by sawyer x 01 May '14

01 May '14

Hey everyone! I just released a new version of Dancer 2. It's a major one. I'd like to share a bit about it. *Semver:* First of all, you probably noticed a completely different release version. Previous ones were 0.12, 0.13, which is why it would make sense for this one to be 0.14. In fact, it is! We've decided to use a convention called Semver[1]. It allows us to indicate to you, the users and developers, what changes we've done. *Changelog:* Additionally, if you check the Changes file, you will see a few more interesting gems. We only have features in this release, there are four changes which were introduced by the same three people (Stefan Hornburg, Mickey Nasriachi, and myself - Sawyer X). *Hackathon:* The reason for many of these changes were a Dancer 2 core hackathon that was conducted at Booking.com's HQ with the aforementioned three core devs last Thursday, a day before the Dutch Perl Workshop. We have worked hard on cleaning up several things that bugged us for a while. Allow me to fill you in on those: *Deliverables:** Replace Config role with better ConfigReader role. * Move App-related attributes (engines) to App instead of config role. Dancer2::Core::Role::Config has been a sore point for a long while. It was pushing attributes to unrelated classes, contained triggers which caused us several attempts to untangle, and was something we wanted to clean up. The new ConfigReader just reads a configuration, allows local and global triggers, and the necessary attributes went into the appropriate class. Yay! * Untangle Runner-Server (removing Server entirely). Dancer2 had a setup of Server handlers (under the ::Server class name), one for PSGI app handling, and the other for a standalone server. The idea was: you call "dance()" (or "start()") and Dancer will either return a PSGI coderef (which goes to Plack) or start a local development web server. Thus we had ::Server::PSGI and ::Server::Standalone. While this makes total sense, it doesn't make any sense at all. First of all, the standalone server is, in fact, a PSGI server. The PSGI server handler (::Server::PSGI) was not a server, but a coderef. Secondly, the standalone server would still need the PSGI coderef. Confused? Good. Now you understand why we wanted to remove it. What we did was keep the Runner class, have it hold a "server" attribute, which will be lazily evaluated to a PSGI development standalone server. If you will need a standalone server run, it will build it, and call it with a PSGI coderef. There is now no ::Server handler classes. That entire layer has been removed. * Replace HTTP::Server::Simple::PSGI with HTTP::Server::PSGI. Since Plack comes with HTTP::Server::PSGI, we could remove a dependency, while replacing it with a much better module. It is more maintained, doesn't require (monkey-)patching (which we introduced in HTTP::Server::Simple::PSGI) and already does all we need. There is now also no ability to daemonize the development server within Dancer2 since 1. Plack already allows it via command line, and 2. you should not be running the development server in the background. If you do, please consider changing it. *Non-hackathon changes:* Cookie building improvements and using Plack::Middleware::Head to serve the head (instead of an ugly around() method), both by Russell Jenkins, and supporting deserializing from DELETE methods as well, done by Russell, Yanick Champoux, and Sawyer. *Thanks:* Major thanks goes to all people mentioned in the changelog in this release: Mickey Nasriachi, Stefan Hornburg, Russell Jenkins, Yanick Champoux, and Sawyer X. Another major thanks goes to our fantastic community. Thank you for the feedback, support, and help! Please try out this new version and update us on any issue you may find! [1] Semantic Versioning: semver.org.

3 6

Problems Directly printing to Apache2::RequestRec buffer with dancer
by Brian Brandes 01 May '14

01 May '14

I'm retrofitting Dancer onto an existing perl application of mine. However, some of the code, for large report generations, will directly print to the web buffer. This is resulting in nothing come back in my response. E.g, with this route handler: get '/buffertest' => sub { my $r = request->input_handle; $r->print("hello world"); # ref $r == Apache2::RequestRec return; }; And then I make a request to it... ==== Begin Request Dump ==== GET http://localhost/buffertest Content-Type: application/json === End Request Dump ==== ... , the response won't come back: ==== Begin Response Dump ==== HTTP/1.1 200 OK Connection: close Date: Wed, 30 Apr 2014 16:37:19 GMT Server: Apache Vary: Accept-Encoding,User-Agent Content-Length: 0 Content-Type: text/html; charset=utf-8 Client-Date: Wed, 30 Apr 2014 16:37:20 GMT Client-Peer: 10.5.15.5:80 Client-Response-Num: 1 P3P: CP="CAO PSA OUR" === End Response Dump ==== IF however, I do something like enable autoflushing ($|=1) then I will get "hello world" back, but that feels like a very brutal hack. Is there an equivalent way to flush response in Dancer?

2 1