Haddock Sanity Check

I never set out to write a web framework. Haddock CMS has always been just the common elements of a lot of web sites that I’ve written and worked on. It’s taken a lot of time and effort but I think that investment will be returned in the long run. Hopefully 🙂

Part of the advantage of writing a framework by refactoring the elements to common to several sites is that it avoids over engineering features. Nothing in the framework should be there because it solves a general problem when a solution to a specific problem would have been better. That would go against doing the simplest thing that could possibly work.

However, I didn’t have a place where I could check that all of the plug-ins for Haddock CMS worked together. There now is one:


If you check out this to a vhost project root, it’s not a very useful site but a good place to check that everything is still working.

New CLI Script class in Haddock CMS

Haddock CMS has always been intended for running programs at the command line as well as on a web server. Separating the interface from the meat of the program has always been an aim, so where the programs are run shouldn’t matter.

So far, command line scripts have been been contained in .inc files. This has worked quite well but it’s overly complicated and hard to maintain.

CLI scripts are now contained in classes that extend a class called CLIScripts_CLIScript. To run a script, first a set of script object runner scripts are generated. These use the reflection API to run the code in the class.

Logical Fallacies

Depressed at the thought of wasting time mucking around with wireless on Ubuntu and worried that I was a Talker rather than a doer, I decided to put together a site that I’ve been meaning to write for more than a year:


The aim is to collect as many examples of logical fallacies on the internet as I can and then analyze them.

I’m getting faster at putting the bits together for a basic Haddock CMS site, although it’ll need to be scripted before many people will want to use the framework.

I’ve got a good idea of the DB structure already (the fun part). Hopefully, I’ll get to write that shortly.

Ad-Hoc Data Serialisation Formats

I’ve been doing a bit of tidying up of the code that goes into the Navigation plug-in for Haddock CMS. An enhancement that I think is quite necessary is to have navigation lists saved in files under version control rather than in DB tables. This makes testing and collaboration much simpler.

The question that any CS student will ask himself is “What format should I use?” I’ve used XML a lot in different parts of Haddock CMS and it is certainly more than expressive enough to be able to store the data for simple navigation lists.

However, it seems like overkill.

Also, I might want to allow users to be able to edit the navigation list specification files in the admin navigation back end.

A simple whitespace delimited data serialisation format springs to mind. This wouldn’t be too difficult to define or implement and I think that users could understand it without too much difficulty.

I started to imagine this language and wrote out a few examples. I started to think about the grammar of the language in BNF. This is definitely an area of programming where the test first approach is very sensible.

It seems that web programmers are very fond of text files and formal languages. I started to wonder about whether there is a version of YACC for PHP and whether such a beast would be a good idea or not.

Haddock CMS site redesign for narrow screens

As promised, I’ve rearranged the divs on the Haddock CMS site to work better on narrower screens.

I made all the edits to the code using Komodo Edit on an EEE PC. The only modification that I’ve made to the EEE PC is to use the full desktop and install Komodo.

Shelling in to my dev and production servers for SVN and to run the various Haddock CLI scripts is not really any different on the small machine. Komodo connects to the dev machine using SCP better on Xandros than it does on Vista (which isn’t hard). phpMyAdmin and cPanel are also fine on the small screen.

While I wouldn’t want to work like this all the time, my main objection is anatomical rather than to do with the performance of the machine. My neck is a little sore.

The only things that I need on the EEE PC at this point are Subversion and TrueCrypt. I’m sure that I can get them working soon enough. Other than that, I would only need the bigger machine for testing what the sites look like other browsers on a larger screen.

Templates and Email Delivery Plug-ins for Haddock CMS

I’ve just committed the first rough cuts of two new plug-ins for Haddock CMS that I quite excited about:



The first new plug-in is a very simple templating engine. I hope to refactor a load of code from various projects into here.

The second started as an OO wrapper around PHP mail(...) function. As always, as soon as I make something into a class, possibilities for inheritance start popping up all over the place and I hope to refactor some emails used in various projects to use this plug-in.

Neither of these plug-ins offers anything ground breaking at this point. They’re more about refactoring, tidying up existing code and code reuse. That seems to have become one of my main motivations for writing my own framework – a refusal to allow my own code to be untidy forever.

DB Pages Plug-in using Haddock OO SQL Queries

I’ve gotten the DB pages plug-in for Haddock CMS to start using the new OO SQL queries that are in the core.

Check out:


It probably makes sense to check out the classes that this extends as well…

Getting the OO model of SQL queries to work has been something of an up-hill struggle. I’m sure to run into more bugs as more queries get written this way. At this point, it’s still considerably more work to write out a query in this way rather than just write it out with HEREDOCs. But ultimately, I think that this approach will pay off.

It certainly has with page, HTML and URL generation in Haddock CMS.