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

Altering Template Toolkit's INCLUDE_PATH in Dancer This just came up on Dancer 's mailing list and I've been sitting on this code (and post) for a few months since the project I was working on didn't need it. Basically Dancer's Template Toolkit view requires you completely alter it or use the default setting. This is pain if you just want to add to it but not have to manage all the changes. I created a new TT view class, to get inside the TT init and add to the INCLUDE_PATH instead of replace it. The code was a bit involved and I extended it a bit by adding a customization flag in each environment (if needed). On to the code Here is the code and config that i used to do this Disclaimer I don't recall all the other issues that i ran into while doing this. It was over 6 months ago but post questions if you have them __END__

As I continue to work more and more with Perl Dancer , I run into situations where I need to pull in application configuration data inside of the template system. Dancer provides access to this config in your template system with the template token settings . What caught me the other day was my desire to use it in the same way as the in the app's DSL: setting . This was my misreading of the documentation. To access settings in Template Toolkit , you must grab sub areas as hash keys. Example: (you can see this in the generated new app code) App name: [% settings.appname %] I did have a case where I wanted to pull in a value that was located in the plugin section. The plugin (like some of them) are named with double colons (::) and I couldn't get the hash key lookup to work so I used TT 's item virtual method. This example dumps out RSS version: Using RSS Output Version: [% settings.plugins.item('XML::RSS').output %] Disclaimer: Of course in the case of so...

I've been creating quite a few  Dancer  plugins recently. The nice part of a Dancer plugin is that it gives a small new set of keywords. In some cases, I've want to provide a generic keyword interface to an object but then provide smarter business level keywords. I've found a quirk in the Dancer::Plugin interface. I couldn't find it documented anywhere but I'm sure it is. If you want to access keywords from the same space that they are registered you need to use a different format than the: register keyword => sub {}; You need to use the pattern: sub keyword { # do stuff } register keyword => \&keyword; register_plugin actually stuffs the symbols into the namespace therefore you need to share the sub names before that happens to use them.

I just realized that I was running an older version in my dotcloud service. There was an update due to a security issue so it was kind of important. I found that I needed to update (or put) a version number in the Makefile.PL . Here is an example of mine. Before: use strict; use warnings; use ExtUtils::MakeMaker; WriteMakefile( NAME => 'leecarmichael', AUTHOR => q{Lee Carmichael }, VERSION_FROM => 'lib/leecarmichael.pm', ABSTRACT => 'Home Site', ($ExtUtils::MakeMaker::VERSION >= 6.3002 ? ('LICENSE'=> 'perl') : ()), PL_FILES => {}, PREREQ_PM => { 'Test::More' => 0, 'YAML' => 0, 'XML::RSS' => 0, 'URI' => 0, 'Date::Parse' => 0, 'Digest::MD5' => 0, 'Plack' => 0, ...

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...

As I was working on a small application that allowed editing of pages, I really wanted to grab the referring page to redirect after the page was updated or the edit session was cancelled by the user. It wasn't very clear to me how to grab the referer from Dancer 's POD documentation on Dancer::Request . Basically I could grab it either of 2 ways. request->referer - nice. This applies to other env options as well forwarded_for_address which pulls in X_FORWARDED_FOR request->env->{HTTP_REFERER} - feels more lower level. I read the documentation as request->env->{referer} which is not correct at all. In the end it is much easier and I think prettier than the several options I tried :) __END__

Quick note to self (and anyone that might be listening): When setting config options different than start and end tag for TT such as PRE_PROCESS in Dancer , you must make them all caps. e.g. config.yaml: # template engine template: "template_toolkit" engines: template_toolkit: encoding: 'utf8' start_tag: '[%' end_tag: '%]' PRE_PROCESS: 'config.tt'