New web content engine: Part 2

I haven't done much talking about my web engine in a while. Part of this is because I haven't been progressing as quickly as I'd have liked, on account of being busy and taking some wrist-problem weekend breaks.

I ended up calling it Rm. What does Rm mean? Well...

One thing to remember is that when you are trying to do something right, but at the same time, are trying to do it quickly, the temptation is to slap on hacks and stuff. But, really, most of those hacks would be counterproductive. I spent a long long time with my current weblogging engine having no ability to actually edit the content of the site. Why? Well, I didn't need to because I was fully prepared to stuff everything into the database by hand. And that's not optimal because I've screwed things up more than once.

So I didn't do the CGI part of things until enough of the fundamentals were in place. I could launch it relatively quickly, but only if I dumped everything into the database and didn't bother with the editing interface. Which would mean it would never be done.

I will say one thing, however. The aspect oriented programming functionality I added has already shown to be useful.

One of the things that's awfully nifty is that I wrappered database access. Which means that Ruby can generate much of the logic. So, can do things like this:

..and that's ALL you need to pull those two fields out of the database. I have a vague feeling that I'm going to be refactoring how everything fits together still more.

I already have the bits that allow you to, with astonishing levels of flexibility, do all kinds of free-form data storage that people normally code in. Normally, a weblogging system has a series of articles, and each article has maybe comments and maybe some sort of way to get images in.

Using my freeform system, things are different. Comments, articles, images, and everything else are all first-class peers. So you can have a collection of articles and each article can contain, as a child, image resources. People can attach comments to articles. This way, images are still kept track of, and relationships can be monitored.

There's a query language at play. It ended up being a great way to separate concerns, but it's proven to be useful. This means that you can transclude other objects into an existing page. You can even insert the queries at multiple levels. See, a page first exists as an XML document. Then, it is interpolated (in the Perl sense) to grab things like queries out. So you can put your query in the content area of a page, or you can have it occur on command. The minor performance hit (which, of course, can eventually be optimized heavily... Ruby is great for embedding C) gives you a lot of flexibility.

I'm going out of my way to make things secure. As far as I'm concerned, getting rooted sucks. And, since I'm going to actually publish the code to this engine, I don't have the advantage of security-by-obscurity anymore.

I took the, arguably rare, step of turning on tainting. This lets me (and I tested, by the way, that it does, in fact, crash with an exception when necessary) make sure that all of the execution paths that involve things like SQL or shell commands are all checked to make sure that you can't sneak in anything you shouldn't be able to. I figure that it'll be better for me to do these sorts of things now, rather than later...