Writing a Dancer Plugin

Last week I was looking at what Dancer had to offer in term of cache plugins. I found Dancer::Plugin::Memcached which had a pretty nice interface, but was unfortunately using a backend that isn’t available on my server. So I thought: “how hard can it be to write a similar plugin that interfaces with CHI?”.

Not very hard, it turns out, and a few hours later Dancer::Plugin::Cache was born.

Writing a Plugin

All the tools you need to write a Dancer plugin are contained in he helper module Dancer::Plugin. To invoke them, you just need to ‘use’ Dancer::Plugin within your module — all the inheritance stuff is taken care of behind the curtain:

package Dancer::Plugin::Cache;
use strict;
use warnings;
use Dancer ':syntax';
use Dancer::Plugin;

With this simple invocation, we have now at our disposal the three functions that module provides: register, plugin_setting and register_plugin.

register()

register() is the most importance of the bunch, and defines keywords that are imported in the application’s namespace when the plugin is used. For example, for providing a ‘cache‘ keyword returning the CHI instance of the application, what we need to do is:

plugin_setting()

If you noticed, I already used plugin_setting() in the definition of the ‘cache‘ keyword. It has a very simple function: it returns the configuration hash related to the current plugin. For Dancer::Plugin::Cache, it’ll return whatever is contained within config->{plugins}{Cache}, which in the YAML configuration file will be, e.g.:

plugins:
Cache:
driver: Memory
global: 1

register_plugin()

This last function is the final amen of the plugin that tells Dancer to go forth and register it with the application. There are no knobs or settings that we have to be aware of. It just needs to be there at the end of the plugin module, and everything will be peachy.

register_plugin;
1;
__END__

Ready to Rock

And that’s it, we are ready to use our plugin (see the source of Dancer::Plugin::Cache for the full working example):

In this case, I think the generic naming makes sense, as CHI is aimed at being the generic way of interfacing with any cache system, the same way DBI is for databases. Buuut I’m admittedly biased and tainted by my secret agenda for world domination. ;-)

Seriously, though, I could easily be coaxed into migrating the module to Dancer::Plugin::Cache::CHI (which I would prefer over P::C::CHI, as the latter don’t carry the information that it’s a caching module for anyone not already acquainted with CHI). Do you know how the rest of the Dancer core team feels about it?

Thank *you* for understanding the namespace potential issues, and agreeing to change the name :) We try to communicate with plugin authors to leave freedom of inovation but keep homogeneous namespaces and equality.

PYTHIAN®, LOVE YOUR DATA®, and ADMINISCOPE® are trademarks and registered trademarks owned by Pythian in North America and certain other countries, and are valuable assets of our company. Other brands, product and company names on this website may be trademarks or registered trademarks of Pythian or of third parties. Use of trademarks without permission is strictly prohibited.