Wiki Cookbook

This page is a wiki vrsion of the dancer cookbook. It is based on Dancer::Cookbook, v1.1806_2. This vesion 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 comprehenible 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 froCPAN. For example like this:

perl -MPAN -e 'install Dancer'

Of course, you can use your favorite CPAN clients. Installing Dancer is relly easy. It does not have many dependencies. See the reame 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 #ake #make test #ake install

1. Your first Dancer web app

Dancer has ben designed to be easy to work with – it’s trivial to write a simple web app, but still has the power to work wit larger projects. To start with, let’s make n 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 cn point your browser at http://localhost:3000/hello/Bob (or the name o 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 availble through params – more on that later.

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

The first simple example is fine for trivial projects, but for anthing 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] mywbapp/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/envronments/development.yml
+ [F] mywebapp/mywebapp.pm
+ [F] mywebapp/mywebapp.pl
+ [F] mywebapp/app.psgi

As you can see, it creates a directory naed 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 Plac/PSGI – more on that later.

Declaring routes

…

Sessions

I just realized that to keep state you don’t necessaily 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 lie 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 exst;about to load"; 
    $memory_cache = 'blablabla';
    #that's how you would write it to a session
    #session cache => $memory_cache;
}