Dancing on the command line

Some dancers (see http://perldancer.org) have expressed the wish to use more of Dancer's features in scripts accompanying webapps (in dancer-users@perldancer.org). To be a little more precise: they wanted to use the config information from a webapp outside the webapp.

I do think that this is a common requirement. You write an app that does exactly what it has to, but not more. For some other aspect (backup, data ingestion etc.) you write a little command line script.  Not everything has to be webapp. Saving time is saving money. A more concrete example. I have a little app that basically displays data from a database. The data rarely changes. If I do get an update, I process it with a little script and put the changes in the database. This data ingestion really doesn't need to be part of the webapp.

Of course, you can simply parse the config.yml file with the YAML module of your choice and go on from there, but Dancer does a little more than that: it also reads an environment file, another config file, and puts the two together, possibly overwriting values from the main config file (config.yml) with values from the environment file (e.g. environment/production.yml). And Dancer also has some default values which are not necessarily also in config.yml (like the default environment, for instance). In short: behind the scenes Dancer does a little more than you might think. You really don't want to implement that again in every little script. Instead, you want to use existing Dancing routines.

It turns out that Dancer may already do what we want. It's just not documented anywhere. And it takes two or three lines instead of one. But, hey, that's not a crime!

Keep in mind: The following are all command line scripts, not webapps.

Example 1: Using just config.yml

Without any ado, magic or too big jumps, you can use the config values from config.yml and some additional default values. It works easy and straightforward like you expect it from your Dancer. 

use Dancer ':syntax';

print "template:".config->{template}."\n"; #simple
print "log:".config->{log}."\n"; #undef 

Please note that the last line will print undef error on a default scaffold since you did not load the environment and  by default log is defined in the environment/xxxx.yml and not in config.yml. Hence undef.

Example 2: Load development environment

If you want to load an environment you need to tell Dancer where to look for it. I think the easiest way is to do so is tell Dancer where the webapp lives. From there Dancer deducts where the config.yml file is: $webapp/config.yml (respectively with backslash on windows etc.).

In this example I use Cwd and FindBin, but you could also just hand over the path like this: Dancer::Config::setting('appdir','/path/to/app/dir'); if you like that better.

use FindBin;
use Cwd qw/realpath/;
use Dancer ':syntax';

#you need to tell the script where to look for config info
my $appdir=realpath( "$FindBin::Bin/..");

Dancer::Config::setting('appdir',$appdir);
Dancer::Config::load();

#getter
print "template:".config->{template}."\n"; #simple

print "environment:".config->{environment}."\n"; #development
print "log:".config->{log}."\n"; #value from #environment/development.yml

In contrast to the first example, now we do have a value from environment/development.yml. We told Dancer where the webapp lives, and by default, it loaded the development environment.

Example 3: Load environment of your choice

So now you still might want to know how to load an environment other than the default.

use Dancer ':syntax';

#you need to tell the script where to look for config info
Dancer::Config::setting('appdir','/path/to/app/dir');

#which environment to load
config->{environment}='production';

Dancer::Config::load();

#getter

print "log:".config->{log}."\n"; #contains value from environment/production.yml

Conclusions

This is tested with Dancer 1.3012

So far so good. My question is if this is elegant enough or if sombody wants some sort of candy to make it nicer. Or maybe there is a better way of doing the same thing. Or maybe we just need to document and test it somewhere.