New web content engine, part 10

So I’ve been running two major sites… this one, and Wirehead Arts. And both of them had weird hacked up largely static-content text based engines to them. First, I rebuilt this site to use Rm, but recently I rebuilt Wirehead Arts to use Rm.

Now, this caused a number of changes to need to be made, which is why I haven’t been posting much up here. Not enough intellectual brainpower to get my day job, this site, and Wirehead Arts all together.

First, I realized that if I used FastCGI instead of mod_ruby, I could run multiple instances without them stepping on each other’s toes. So I set up Wirehead Arts using the Ruby FastCGI library, which ended up being incredibly simple. I was surprised. Kind of like how there’s a “Dispatch” script in Rails that handles the case of building an environment and figuring out how to direct the URLs, I’ve got a “rmcgi” script that is exactly the same for CGI and mod_ruby and minorly different with FastCGI.

I will probably eventually use Rack, but not yet.

Second, I needed to complete the code necessary to run two very different looking installs of Rm under a single source tree.

Now, much of the changes are already in place. See, there’s a configuration file that supplies all of the important details for a given install. How the URLs are to be constructed, which database to connect to, etc. I also use that file to list off which classes are actually enabled.

Now, the big problem is where to put the scheme. I kinda took the easy route on this one. A scheme is a directory with the XML template files, a subdirectory for all of the static content like icons and CSS, and a single Ruby file that monkeypatches an existing Rm install. This way, I can have two very distinctive looking sites and you can even swap out things like the rendering code for lists and boxes.

The templates are pretty much designed so that you can sit down and mock up the layout in plain old XHTML and then you just insert XML tags to add the content. Very simple. I’m realizing that my current job, even though I do absolutely no web design of any sort, is rubbing off on me.

So I spent every weekend the last month and a half either traveling or hacking on Rm to get the new Wirehead Arts together. And the funny part is that when I switched gears back to this site, there was only one change that needed to be fixed up. Everything else just plain worked.

I was talking with a friend about a site that she’s been working on and I realized how much Drupal really sucks. See, excepting features I haven’t implemented yet, my setup is much simpler, conceptually. In Drupal, there’s these layers and layers and layers of stuff between you and the database that conceal what’s really going on and mean that you have to understand not just PHP but the layers of abstraction that Drupal adds. Whereas here, even though there’s not a fancy visual interface, there’s a single layer of abstraction.

One of my next projects has to be figuring out how one would run Rm on the multitude of inexpensive web hosts. From what I can tell, most of the good ones offer FastCGI + Ruby + PostgreSQL. However, I’m not sure how they handle the contrib modules that I use.


Posted:

Updated: