Notes, How Tos, Things To Remember, Things I'll soon forget

A few weeks on #dancer channel, a user was having issues using Dancer::Session::PSGI . I've never worked directly with Plack besides reading the handbook and few play apps. (well a few weeks ago, I dug into Dancer::Debug .). Using both together was an intriguing problem stuck in my mind. The person on the channel was reporting unreliable reading of session data and other odd behavior. As I started to dig into the problem, I realized that i need to create two apps, one pure Plack and one Dancer with middleware wrapper. I created a public repo on github with my test apps: Dancer and Plack session . Since, I didn't want to deal with html and wanted a bit of structure with return data, I made both test apps return JSON and have pretty simple routes I started off using the documentation from Plack::Middleware::Session to create this test app : Next I created a Test Dancer PSGI app , which basically had a way to show value and update it. Here is the non-exciting Dancer ...

The other day someone was asking how to enable Template Toolkit debugging inside of Perl Dancer in the #dancer IRC channel, it seemed like a good time for a write up. The template engine configuration directive supports passing through various options like start_tag and stop_tag as explained in Dancer::Template::TemplateToolkit POD. And alludes to being able to pass other options. How To pass TT options like those found in Template::Constants , there must be a DEBUG section in engines -> template_toolkit , usually found in config.yml . Example Snippet Here is an example: A few notes Remove leading DEBUG_ from TT constants. The option DEBUG_PLUGINS becomes plugins . Multiple options can be separated with a comma. Example: DEBUG: "provider,plugins" . Be warned, some of these options can lead to tons of information :) __END__

Bring together the parts I was able to find complete documentation on running dancer  with nginx using FastCGI. In the dancer deployment  it discusses using Apache and fastcgi or nginx with proxy. Often, using nginx as proxy to starman(or some other plack webserver) is probably the right thing. But sometimes using fastcgi is good idea too :) I'm running some benchmarks but it seems like memory usage is a bit smaller with FCGI but I still need to do more digging on this. Make it so Lets get all the parts install and then configure them Install the Parts Note: These parts will be very dependent on your system. I'm assuming a debian/ubuntu system below. First you need to have nginx and dancer installed. For nginx i would recommend doing something like: apt-get install nginx or building and install from source.  Next, install need Perl modules: cpanm + Dancer's Makefile.PL I like to install using Dancer's app generated Makefile.PL along with cpanm ...

Dancer does lots of great things. It has a nice clean way to define routes to handle AJAX routes using the plugin Dancer::Plugin::Ajax . ajax routes are defined in a clear way: ajax '/stuff' => sub { # do work and return }; This plugin technique allows for clear way to separate between ajax and other types of actions for the same route. ajax '/stuff' => sub { # do ajax-y stuff here }; get '/stuff' => sub { # handle html response }; Unfortunately, the one negative with Dancer::Plugin::Ajax is that is assumes all responses will be XML. A quick fix is to manually set the content type in each ajax handler. ajax '/stuff' => sub { content_type('application/json'); # do work }; or add set it as a general option in your main before hook or in each prefix route handler like: package WebApp; hook before => sub { if ( request->is_ajax ) { content_type('application/json'); } }; ...

Dancer is a great framework. It does a great job making a default development work out of the box. Its a nice alternative to some of the heavier ones that require quite a bit of setup (actually most Perl web frameworks do a great job of this). Also it makes sure to serve static content (to avoid deployment issues, I assume). But compared to nginx or apache it is much slower at serving this (not a big surprise). In my dotcloud deployments I've found this to be a bit confusing to make sure nginx handles it instead of Dancer . My first pass at this was setting up these symlinks in my source tree: static/css --> ../public/css static/javascripts --> ../public/javascripts and such. It felt wrong to have this inside source control so I dug around a bit and ran into the postinstall script that is supported by the deploy dotcloud command option. I added the following link commands to mine to create those nice symlinks: #!/bin/sh # used for dotcloud deployment...

I'm in the process of rewriting my site www.leecarmichael.com . I really wanted a reason to build a small but real app with (Perl) Dancer . I really like most of Dancer 's approach to routing and layout. It fits well with my way of thinking of web apps. At the same time I stumbled onto Dot Cloud , a very well thought out and incredible nice deployment provider. They are part of the current cloud shift in which individual application stack layers are hosted instead of a full OS stack. Here are the few gotchas that I found: They deploy using PSGI and Plack, very cool. But its deployed with an environment of 'deployment'. This means you must have a deployment configuration file. Example: application_root /environments/deployment.yml . I found this confusing since i expected it to follow the Dancer approach of production (my own bad assumption) Unfortunately, runtime errors are not logged to the standard web server error log (or anywhere else). Therefore you need t...