Apart from keeping busy with dragonboat racing and co-hosting a net radio show, I've been spending the bulk of my spare time on Code Blue. I work on it when I'm riding the train to and from work, and at least a couple of nights per week once I get home. I think about it in the shower and in the car. I work on it all weekend, before I go to bed and when I wake up in the morning.
In my experience, a group of (what I shall randomly classify as) "typical" websites can use around 90% common functionality in the back end. Since the year 2000 I've been wanting to take advantage of this fact, and implement a single system that could deliver a core set of features across all of my web sites. Unfortunately, the reality of day-job overtime has never afforded me much of an opportunity to work consistently on any of my own projects, beyond anything that was a few hundred lines. Prior to coding the latest incarnation of the Risto.NET code base in 2005, I spent some extra time upfront planning the system and standardizing the data models. The plan, as always, was to stay away from code that would be specific to this website, so that when the time came I could expand it intelligently, and create a single code base that could be applied across all of my website projects; my own CMS. Of course making things (more or less) generic takes five (or ten!) times as long, so in order to release this site within a reasonable timeframe some areas of Risto.NET still use custom code.
When the Something About Midnight project came up I decided to enter a code freeze on Risto.NET, and to begin work on my CMS. I spec'd out the system at a high level in order to determine whether or not it was a feasible project to pursue, or if I should continue creating independent sites that each had their own versions of similar functionality. I determined that even a custom site would take a few months, and so it was time to start my CMS.
The first step was to define exactly what functionality my CMS should provide, and the second step was to come up with a name. After defining the feature list, I pored over a myriad of semi-applicable names and epithets. I was looking for something thematic and with a nice ring to it. "Net Engine," "Site Engine," ... "Web Nucleus?" Thematic to be sure, but lacking in the nice ring department. Unable to come up with a name, I created a list of keywords, but even on their own these were too ugly to look at, so I decided to begin with something that had no meaning: "blue," my favourite colour. But, "blue" alone wasn't quite enough. Hmm.
Today, after just over a month's worth of free time devoted to design work, I'm ready to start coding. I've got the functionality and database tables grouped into modules and defined their interactions. I've examined the types of content that might go into the system within the next few years and created a unified and extensible content model to facilitate all the content types I'll require, and I've determined the features I can reasonably produce working on my own. I've taken a look at some of the major open source CMS projects to determine if I could get away with using one of those rather than coding my own, but I discovered I don't want to. This is a problem domain I want to explore, beyond the simple avenue of download and deploy. Also, I've noticed that not all CMS's manage all content using the same API, and it's often requisite to write your own custom extensions in order to manage custom types, not just custom fields. In Code Blue all content will be managed via the same API. The content data model will truly manage every content item, for every content type (MP3s, blogs, quotes, images, et cetera), for every website. No more get_all_blogs(), or get_random_mp3s(), now it's just content::get().
With other CMS's it can be a headache separating content type attributes (i.e. individual data fields such as 'title' and 'date') from the HTML templates. In Code Blue each content item will be bound to a content type, and each content type will have its own schedulable html templates. When a content item is parsed into a page it will be wrapped in its HTML template before being returned to the front end, as opposed to retrieving the content item and then wrapping it in HTML once we're already in the front end code. I have no need for anything more than basic conditionals within templates, and even in this case, I'd like any logic that resides in templates to be simple enough for any designer to comprehend.
Another benefit of having every content item managed via a single data model is that the parsed HTML for every item is cached the same way, there will never be any special cases to manage; either an item's cache needs to be updated, or its cache row is up to date. Changes that trigger updates for a cache row are managed via a dependency table. For example, a cached row for an item of the blog content type will require updates if its HTML template is modified, if its blog entry is modified, or if the template variables used in the HTML template (colors, table widths, et cetera) are modified.
Frontend HTML template production time will be reduced dramatically, because the only work required when creating the frontend is the site layout (HTML tables, CSS containers, et al), and placement of content within this layout. HTML templates remain clean, and to the point. The only work in setting up a site will be template design and content population.
Some of the existing CMS programs would allow me to write my own components and/or modules in order to achieve the functionality I'm looking for, but the problem is that they aren't all 100% flexible with respect to content placement. In any case, regardless of content placement, it looks like I would have to make major programmatic modifications just to add the functionality I require. For example, to facilitate the random image header at the top of my site.
If I'm able to find the time to work on it, I hope to produce a semi-stable version by next summer. Realistically what I may complete is the minimal functionality required to run the Something About Midnight site for some time this fall. Perhaps even more realistically, I'll end up using Mambo.