Cub - File Base Publisher.
A few days ago i started work on a new side project, a tiny site publisher inspired by Textpattern, Jekyll and Second Crack.
The basic premise is simple, i wanted an easy way of publishing blog posts and longed for something “simple”. There are loads of static site generators and CMS’s out there, so you may wonder why i choose to create yet another one. Well, boredem and curiosity i guess!
Cub consists of 3 parts, a tag engine (lifted from Textpattern), a file parser (borrowed heavily from second crack, at least for now) and a renderer (i wrote that bit).
Like Textpattern, Cub tries to keep the code simple. It’s precedural and fast. It renders content out to HTML as quickly as possible and then caches it to save the effort in the future. Uncached pages render in 20-50ms and cached pages render around the 11ms mark.
Cub is not truly static, each page is generate at request allowing for the intergration of dynamic content such as comments and twitter feeds.
The tag parser and the structure (section, page, form) is from Textpatten (hence Cub is GPL) but the implmentation behind most of the tags is bespoke. The and structural tags (like
So far the main challenge has been working with flat files, specficially retreving data sorted by ‘posted’ date. As far as i can see there are two methods.
The first method uses the file names themselves, prefixing the file name with the posted date so content/hello-world.md would become content/2012-10-08-hello-world.md. This then allows you to easily output files in posted date order.
The second method is a little more complex, but alot more flexable. Inside each file there is a piece of meta data containing the date the content was posted (eg “posted: 08-10-2012”), when rendering this information is used to sort the posts.
The second method has a big drawback, it requires the reading and processing of every file in a given section to render the index page. This is less than ideal.
In practice the performance cost seems to be minimal, in a quick benchmark comparing method two to method one the difference was less than 10% (over 128 content files). The flexibilty comes from the meta data format, method two could potentially sort by any peice of metadata so thats the way i have gone for now.
Right now, cub is an experimental project. Its been very enjoyable hacking on something simple and lightweight. I intend to keep pushing on it too see where it goes.
Cub is up on github, feel free to take a look at github.com/jamieknight/cub.