Home » Blogs » Maurice's blog

Beginner's dance class

Submitted by Maurice on Wed, 09/01/2010 - 22:09

Beginners' Dance Class: http://www.youtube.com/watch?v=y64Ynur-veU

Perl turned 20 a couple of years ago. It has been with us since the Web has learned to crawl. Long before php, java beans and web application frameworks. There is tons of old perl out there, but there is also new perl code which runs on modern websites. Sometimes it is hard to find what is what.

Most web frameworks assume that you already know a lot about the web, that you did a good part of the evolution from cgi scripts, to the CGI module to frameworks like Catalyst. Or that you know some other framework (sinatra) in some other language (python, ruby). To begin at the absolute beginning, but with a modern approach in perl has almost been impossible. Until now that Dancer is getting mature enough.

Dancer is different. If you haven't used perl in years, or if you just became acquainted with it, it doesn't matter. You can write your first web application in minutes. And then you can learn as much as you like in the speed you prefer.

Dancer is young. About a year. The community is still somewhat small. According to the notoriously non-trustworthy ohloh, it's mostly located in Western Europe/France (http://www.ohloh.net/p/Dancer_cpan).  In fact, Dancer lives on github: http://github.com/sukria/Dancer. It is very active. With a few changes almost every day to it's devel branch. At least at the moment.  Very nice and helpful community at the mailing list dancer-users@perldancer.org. Also have a look at the project's homepage: http://perldancer.org.

At the moment, documentation is not really pretty. Most important things are there and they work, but there could be more stuff for the beginner.

Both code and documentation is easy to find, use and access via CPAN at http://search.cpan.org/dist/Dancer.

I am trying to write up something that helps beginners. At the time of writing, Dancer's most current version is 1.1810.

I try to write up something here for beginners. What I write is based on Dancer::Cookbook, but I add some stuff that I think is helpful for beginners.

Install

You simply need to install Dancer from CPAN. There is more than one way to do it, e.g.

$> perl -MCPAN -e 'install Dancer'

Dancer doesn't have many dependencies, so install is usually painless. No matter which way your preferred way of using cpan is, -- cpanplus or cpanminus etc. -- it should install the dependencies automatically.  As we all know, it's not that easy all the time, so it's good dancer doesn't require that much to get started

 CPAN currently shows these non-core dependencies:

  • HTTP::Server::Simple::PSGI
    • HTTP::Server::Simple::PSGI
  • URI
  • HTTP::Body
    • HTTP::Headers
      • HTML::Tagset
      • HTML::Parser
    • Test::Deep
      • Test::Tester
      • Test::NoWarnings
  • MIME::Types

More on dependencies in Dancer's README.

Your first dance

Dancer comes with a helper script called dancer. Execute

$ dancer -a webapp

and the script will create a new webapp for you. More precisely, a folder with the name "webapp" in the current directory with several files in it. At the moment, you don't need to understand what all the files mean. What is important is how you can start your application. That's extrememly easy:

$ webapp/webapp.pl

When you start your application like this, dancer starts in standalone mode, creating a http server (a web server, basically) just for your application. By default you can find that server at http://localhost:3000.

If you like, you can change the defaults by changing webapp/conf.yml, see the Dancer::Cookbook and Dancer for details.

This standalone mode is very good for developing. It is generally not good for production. The main limitation of the standalone server is that it processes only one request at a time. That means if your server is busy processing a long-lasting request (your great perl work), it will not respond to other requests.

There are dozens of ways of deploying your dancing web application on a server, see Dancer::Deployment. There is no need to go into this topic right here. Since Dancer complies with the PSGI specification (see CPAN) makes Dancer work together will many server setups.

Looking at your first dance

Your code actually resides in webapp/lib/webapp.pm. If you open that file you find something like a complete "Hello World"-kind-of application ready for you.

package webapp; use Dancer ':syntax'; our $VERSION = '0.1'; get '/' => sub { template 'index'; }; true;

What this  does is to wait for incoming requests on the server root (/). With default settings that's http://localhost:3000/.  Visitors of that url are served the index template located at webapp/views/index.tt which contains

<h2>It Works!</h2> <p>I'm in <code>/home/Mengel/projects/webapp/views/index.tt</code></p>

So if you start webapp/webapp.pl and visit that url in your browser, you should see a html page with that heading and that one sentence.

Routes: Finding partners

In the webapp world rules which match the incoming request with some code are typically called routes. To stay in the dancing metapher, why not compare it to finding a dance partner.  Let's look at the example above again

get '/' => sub { template 'index'; };
"get" refers to the HTTP protocoll. You could also specify "post" and a whole lot of other stuff. '/' is the root. You could specify any kind of path, e.g. '/this/is/a/more/compex/path'. And there are many gimmicks that make routes in dancer fun, e.g. wildcards, named parameters.

There are some features in dancer to make some nice routes, see Dancer::Cookbook for a better list.

Dancing with style: Explicit returns

get '/' => sub { "Hello Word"; };
Perl has a somewhat weird way of dealing with return values when you think about it. As long as you don't think, it is often just fine. Perl does what you want and it looks good.
The example above returns "Hello World" and prints it on the screen much like the template before. But I don't consider this good style. If code gets more complex you easily lose track on which sub returns what. For example if you just add a debug to try things out, it doesn't return the string anymore
get '/' => sub { "Hello Word"; debug "this message"; #return value is '1' now };
So I urge you to always write at least one return per sub (unless you are dealing with objects which change themselves, obviously).
Next: Logging, debugging, sessions

 

No votes yet
Theme provided by Danetsoft under GPL license from Danang Probo Sayekti