New web content engine: Part 3

I got distracted by a few big things in my life of late, so I put the code away for a while. Lately, because I’ve been wanting to change gears a little bit on my recreational coding, I went back and dusted off my code and took a fresh perspective on things.

I’ve been in a weird state where the code base grows a bunch and then shrinks some as I realize that there’s repeated code and I can take advantage of Ruby’s metaprogramming functionality to shrink the codebase.

For example, I’ve got a set of data structures that are intended to mirror the class structure in a variety of ways to provide a “sanitized” way to call arbitrary methods. I started out cut-and-pasting the code, but then I sat down and replaced most of those methods with a smaller set of parameterized methods once I realized that they were all the same with one or two parameters different each time.

I also decided that I was spending too much time working on features that are simply not important for getting to the alpha-test cut-over point where I replace this site with a Rm-based version of it. And this is a problem, because I kinda realized that I wasn’t doing anything with this site because I didn’t want to make the eventual re-porting process any harder, so I wasn’t modifying anything here.

I also decided that I wasn’t going to launch the site until I could install it on a bare machine and add new content by hand myself without any manual operations. So I’ve been spending a LOT of time writing the best possible scaffolding for an astonishingly limited amount of actual functionality.

I did make one fairly substantial change in development direction. In 2001, everybody figured that eventually all websites would be coded in well-formed XML and with XSL:FO, XSLT, and CSS turned into readable pages. I designed several websites under this assumption, but as far as I can tell, this is not going to work out. The problem is, it’s a fairly esoteric language that only somebody comfortable with functional programming will get full use out of. Your average web developer will either not understand the language at all or will find it sufficiently uncomfortable that it’s not worth using. Most of the advantages — including the ability to accept arbitrary user input safely over the Internet — are also present in Ruby.

So, I ripped out all of the XSLT from my code. I thought about using one of the existing templating systems for Ruby. I might still add the ability. But since I’m still trying to do higher-ordered behavior with my system, I decided to write my own templating system.

The end goal is this single line from a template file: <query:field target="posting"/>

The field “posting” is defined in the page class’s YAML metainformation file with what kind of data it should be and what the specifications of it are. The system is able to insert either an HTML control or an AJAX control. It doesn’t matter if you are editing the page or if you don’t have rights to edit or if you are creating a new page… it will always do the right thing. It’s not there, but it’s close.

The delay also helped me figure out in my brain what the proper way to code some of the edge cases was. For example, I hadn’t done a very good job when I had first tried to create the “insert a fresh node into the database” tool. What I realized, after a brief delay, is that what I really wanted was the ability to do static class methods as well as methods on individual objects. Once I figured that out, it was easy.

I also spent some time playing with Ruby on Rails. I can see the huge advantages of using Ruby on Rails. You can construct a database-driven application quickly. It plays nice with SQL. However, it has a lot of built-in assumptions. The problem is, they need to write up a few page document that explains what not to do that you need to read before you get started. Some of it it the sort of thing where you just have to type a few extra lines of code (for example, if you don’t follow the naming conventions exactly) and some of it is the sort of thing where if you structure your database like this, all sorts of stuff will mysteriously not work.

With all of this hacking, I feel justified that the web framework that I’m writing will be optimal for different problems than Rails and therefore is worth pursuing.

So, right now, I’m just about ready to do alpha testing where I replace most of with the new system.