Miril Gains Plack Support, Command-Line Interface, and More

A fresh new release of my pet project, Miril, is already on CPAN. Miril is the content management system that powers this blog: read about why Miril was created or have a look at some screenshots.

Here is a breakdown of the notable changes:

Edit and publish from the command line

This release makes it possible, and easy, to edit and publish content without using the web UI at all. Two major changes have taken place to achieve this:

  • The data file format has been changed and and is now pretty easy to edit by hand (check the samples in the example/sites/example.com/data directory in the distribution)
  • You can use the newly added miril script to publish content from the command line. Just run miril publish -d $miril_base_dir -s $website

Manage multiple websites from one Miril installation

Miril now expects to find data and configuration files in a specific directory structure. You have a base miril directory (e.g. ~/miril), which in turn contains a sites directory which contains one directory per individual site. So anywhere you run the Miril application (e.g. from the command line or from a cgi script) you can specify which particular site you want to manage.

Plack support and bundled standalone server

The Miril::App::PSGI module now returns PSGI app representing the Miril application. So anything that Plack supports now, Miril supports it too. In particular, the bundled miril script can run Miril as a standalone server (miril server -d $miril_base_dir -s $website).

New List API

A major new feature of this version of Miril is the addition of a brand new List API. Lists in Miril are pages that contain a list of posts, e.g. a front page with recent news, a rss feed, etc. The templates which generate such lists are now passed a much more powerful Miril::List object (as opposed to simply an arrayref of Miril::Post objects). You can now do cool stuff such as displaying post archives a.la. Movable Type style (have a look at the archive section of this blog), create paged lists, and more.

Comprehensive code refactoring, which matters because ...

This one requires a little bit of history. One of the primary goals of Miril from the very start has been to be extremely easy to install. And by extremely easy, I mean the initial design was to bundle everything into a single CGI script (using something like App::FatPacker) and ship that to users. In order to achieve that:

  • Miril's UI was designed to use no images, and the CSS was embedded in the pages, i.e. everything in the UI was created dynamically without using any external resources (images, css files, javascript, etc.). This principle actually still holds
  • Second, and more important, Miril was designed to use only a minimal number of dependencies, and ones whose code was spread among the smallest number of files as possible, and which in turn had vary simple dependencies too, so as to keep the total number of files to be included in the resulting single script in check. Where a task required a module that was too complex to include, I would rather rewrite the needed functionality from scratch than add such a module to the dependencies.

This strategy, of course, turned out to be unsustainable. I ended up using code I did not necessarily liked, and rewriting code I should not have. Hacking on Miril evolved into an unpleasant grudge.

Currently I am targeting shipping Miril to regular users as a zip archive instead, with everything bundled in a local lib, rather than as a single file. This means I can be much more liberal about dependencies (as long as they and their dependencies are pure perl, of course). The code has been completely refactored and reorganized in such a way as to allow individual components to be gradually replaced. Things I am looking forward to experimenting with are using Mouse (which would be extremely suitable for the base content classes such as Miril::Post, Miril::List, Miril::Topic, etc.), adding an alternative web UI based on Mojolicious, using Template::Declare for the generation of the UI stuff and Template Toolkit for the publishing process, replacing Miril::DateTime with DateTimeX::Lite, better ways to do form validation and generation (maybe FormValidator::Lite), and more.

Other small changes

  • A few features have been added to allow easier creation of Atom feeds, such as the iso property of Miril::DateTime, which returns a date in an ISO 8601 format, and the tag property of Miril::URL, which returns generates a RFC4151-compliant tag URI from a URL.
  • There is now basic form validation for the web UI
  • Better support for UTF8 content

A word of caution: Miril is still more of an experiment than stable production-quality software. It most definitely has bugs, and parts of the API are most definitely bound to change. If you plan on playing with Miril be sure to get in touch with me (the dedicated but currently empty google groups list is one way to do this).

Posted in Miril
blog comments powered by Disqus