Wiki Cookbook

This page is a wiki version of the dancer cookbook. It is based on Dancer::Cookbook, v1.1806_2. This version will grow according to the user input, so feel free to contribute.

The official cookbook is more concise. This wiki version can be more verbose. The idea is to explain Dancer’s basic feature by practical and comprehensible examples. Maybe we can even tweak in a little of that humor that was part of Tom Christiansen’s classic perl cookbook.

Recipes

Installation

Usually you will install Dancer from CPAN. For example like this:

1. perl -MCPAN -e ‘install Dancer’
   

Of course, you can use your favorite CPAN clients. Installing Dancer is really easy. It does not have many dependencies. See the readme file that comes with Dancer for current info on dependencies.

Dancer is developed on Github.com. So why not install directly from there? Then you will need to build it yourself, but it’s really easy.

#git clone http://github.com/sukria/Dancer.git Dancer #cd Dancer #perl Makefile.PL #make #make test #make install

1. Your first Dancer web app

Dancer has been designed to be easy to work with – it’s trivial to write a simple web app, but still has the power to work with larger projects. To start with, let’s make an incredibly simple “Hello World” example:

#!/usr/bin/perl

use Dancer; get ‘/hello/:name’ => sub { return "Why, hello there " . params→{name}; }; dance;

Yes – the above is a fully-functioning web app; running that script will launch a webserver listening on the default port (3000); you can point your browser at http://localhost:3000/hello/Bob (or the name of the machine you ran it on, if it’s not your local system), and it will say hello. The :name part is a named parameter within the route specification, whose value is made available through params – more on that later.

Note that you don’t need to use the strict and warnings pragma, they are already loaded by Dancer.
Starting a Dancer project

The first simple example is fine for trivial projects, but for anything more complex, you’ll want a more maintainable solution – enter the dancer helper script, which will build the framework of your application with a single command:

$ dancer -a mywebapp
+ [D] mywebapp
+ [F] mywebapp/config.yml
+ [D] mywebapp/views
+ [D] mywebapp/views/layouts
+ [F] mywebapp/views/layouts/main.tt
+ [F] mywebapp/views/index.tt
+ [D] mywebapp/environments
+ [F] mywebapp/environments/production.yml
+ [F] mywebapp/environments/development.yml
+ [F] mywebapp/mywebapp.pm
+ [F] mywebapp/mywebapp.pl
+ [F] mywebapp/app.psgi

As you can see, it creates a directory named after the name of the app, along with a configuration file, a views directory (where your templates and layouts will live), an environments directory (where environment-specific settings live), a module containing the actual guts of your application, a script to start it, and an app.psgi file – this will only be of interest if you’re running your web app via Plack/PSGI – more on that later.

Declaring routes

…

Sessions

I just realized that to keep state you don’t necessarily need session. In case you want to keep some variable in memory you could, of course, simply use a class variable. Might help webapp beginners like me to put it in the cookbook. Looks like this and of course, it works elsewhere (i.e. outside of before) just as well.

our $memory_cache;

before sub { 
  if ($memory_cache) {
    debug "cache exists";
} else {
    debug "cache does NOT yet exist;about to load"; 
    $memory_cache = 'blablabla';
    #that's how you would write it to a session
    #session cache => $memory_cache;
}