WireWorld » Hacks » Wirehead on Hacking » New web content engine: Part 1

New web content engine: Part 1

The code behind this weblog is starting to get a little moldy. It was written quite some time ago using a MS Access database and VBScript Active Server Pages. Which, after Sitehosting.net (a.k.a. Affinity Internet) went down for several days, was hastily ported over to PHP and PostgreSQL.

I've been working on the replacement, lately. This is the first of many weblog entries describing my progress on writing it.

The first thing to know about it, and if you didn't notice from the other geekly weblog entries, is that it's written using Ruby and PostgreSQL.

Now, Ruby's a simply amazing language. There's all kinds of interesting contortions that you can put the language through. And PostgreSQL is a similarly amazing database.

Mostly because it's rather convenient, the entire formatting engine is entirely W3C-compliant. I've already got XML DTD's and XSLT style sheets to translate the format that the non-weblog parts of the site use, so those are going to be reused. XSLT, when you get down to it, is really just Lisp in disguise.

The entire contents of the site are going to be managed within the content engine. Previously, there was a Python-based image database on my machine and some more Python code to translate the pages of the site using XSLT, and then the ASP(then PHP) based weblog code. This time, everything is done with a single system.

This, obviously, means that I have to be able to store things in a hierarchy. But I've got some weird twists ahead there, both on the coding side and on the organization side. I'll speak more about that one later.

What I've got right now is a shell interface for the prototype code for the site and the database schema.

I'm inspired by how Rails works, but I'm not using Rails for this. I am, however, freely stealing ideas.

Unlike Rails, everything must be explicitly exposed within a data object. It looks something like this:

`

class BaseNode
  #...
  cli_access :display
  http_access :display
end

`

Which means that the function "display" should be accessible via both the CLI and on the web. The neat part about Ruby is that it lets you do things that are a little resemblant of the Dot Net attributed programming, except that they don't require anything that's not already in the language.

Also unlike Rails, every object must be registered, because I'm not having individual CGIs. So that code looks like this:

`

class BaseNode
  #...
  register_dbclass "wh_root"
end

`

So that, this way, the object behind a given page can be located easily.

If you check out syntax, that's exactly matching the syntax of all of the other functions to expose or protect methods or variables in Ruby. This is why Ruby is so cool, naturally.

There's also aspect-oriented programming functionality here, so that you can add what they call "Crosscutting" concerns like authentication, benchmarking, and more.

Now, you should notice that I mentioned a CLI above. Just to get everything testable early-on, while I add features and functionality, I wrote a quick-and-dirty CLI system using regular expressions, so that I can browse the database objects and trigger behaviors on individual objects. Because I would like to eventually have SOAP or XML-RPC available within the system, the functionality will be useful later.

There's more geek stuff, but that's the highlights. And I don't want to get too far ahead of myself because everybody's got ideas about how things should be; what really matters is actually doing things. ;)

Now, the one thing to be said about hierarchies is that they break down. There's considerable research in the library and information science field about this. I mean, really, if you are categorizing cars in a hierarchy, what do you want to do? Would it be Cars -> Honda -> Accord -> 4 Door -> Gray -> 1989 or Cars -> 1989 -> Honda -> Accord -> 4 Door -> Gray. Or maybe Cars -> 4 Door -> Honda -> Accord -> 1989 -> Gray.

This is what leads people to a search engine for a site, but that's not entirely optimal.

There's some other ways that are already heavily thought about by those who know what they are doing. I'll be using at least some of them. If you want to think about it, for now, it's Left As An Exercise For The Reader. ;)

One of the goals here is to make a better image gallery for my purposes than stabilize.net. Because, as everybody knows, writing something cooler is one way of doing mean things to one's pointy haired boss. I mean, I'd put something in his food, but I'm not sure if there's anything he wouldn't appreaciate having in his food. I mean, really.... I'm doing it for my purposes, so I can definitely say that I don't need all of the functionality present.

But it will definitely be cool in new and different ways.

Comments