Welcome back.
My apologies for the delay. I blame trying to keep up with the QA hackathon from half a world away, and another unavoidable event from which I could not escape.
I’ve also delayed another day because I’m a bit concerned that my review this week would paint Mojo in an unfair light, and I wanted to sleep on it.
As I get deeper into both, I’m finding that many things I don’t like about one turns out to have a similar behaviour in the other. As a result, whichever one I review first would be the one that a stream of consciousness commentary will paint in a worse light.
And I’ve wanted to start each week with Mojo first, as the more established competitor. But I think this might be unfair given the emerging similarities.
So each week I will reverse the order I review them in, and this week I shall attempt to emulate finding my annoyances in Dancer first 🙂
This week, I had originally planned to look at configuration and database.
Like in many projects though, this turned out to be way too trivial because I’m basing the website on the CPANDB module, which is zero-configuration.
So in BOTH applications, I only had to add the following and I have my database layer finished 🙂
Use CPANDB {
# Don’t check for updates more than once a day
maxage => 86400,
};
Instead, I’m going to look at the second phase for most website projects as a newbie. Bootstrapping from helloworld. pl into an equivalent “proper” website with templates, images and CSS, but no actual content.
Dancer – Bootstrapping a website
Since my review last week, a couple of new releases of Dancer hit the CPAN claiming to fix installation on Win32. Just to prove it, I’ve done this week’s testing on my conference presentation laptop instead of my desktop machine.
Dancer installed first time cleanly on the new machine.
And the hello world script from last week runs correctly. So all good there.
After a more-complete-than-last-week read through the main Dancer search. cpan. org page one thing jumps out quite sharply about the Dancer API in general. And this is that it isn’t object-oriented, which is something or a rare thing these days.
Or at least, it doesn’t LOOK object-oriented. Judging from the distribution page there’s plenty of classes and I’m sure the internals are all done largely in an OO fashion.
The main API that you get with “use Dancer” sports a similar kind of “Do What I Mean” command interface that reminds me a bit of the Module::Install command interface.
This means that the code to show the index template is going to look like this.
Get ‘/’ => sub {
template ‘index’;
};
I’m not entirely sure what I think about this idea, despite the fact that I’m the maintainer of M:I and created it’s Domain Specific Language inteface. This kind of thing usually raises red flags.
I can see this API strategy either descending into API chaos or becoming one of Dancer’s best and most loved features. Or quite possibly both depending on the scale of the project.
For the moment, given Dancer is meant to be taking a micro-framework approach (which should be optimised more for small websites) I’m willing to suspend my disbelief and run with it until I can make a better judgement.
The documentation in general is oddly structured. For a command-oriented API like this I would expect to find documentation for each of the available commands. This section of the documentation does exist, but it doesn’t contain a list of all the commands.
(No Ratings Yet)