Why I created Rior

In 2005-2007, I was working for a company that did website work. A lot of our (the programmer's) pain at the company was collecting information out of the database for display to the web and putting new information into it.

In early 2007, I hit upon an idea for a cleaner template system that would make it easy to build dynamic web pages without having to learn a template language. That's overstating what is done with Ante, but that was the aim. In the back of my mind though, was how I could create an easier way to retrieve information from the database to pass to the template engine and then pass input information back into the db without having the programmer much involved in the process.

Not an Object-Relational thing.

Many developers upon noticing a need to pull data out of the database and then passing new information back head for Object Relational mappings or similar. While these are extremely useful, I think that for the web, they're the wrong way to go about it.

Resources and Representations

I'm going to borrow terminology from the REST architecture style to explain myself. Each row (or set of rows) in a database table can be considered a resource and a dynamic web page is about mapping the information contained therein into html representation.

What does that mean? Well, reading up on REST is a good way to start, but different people seem to have a very different understanding of the meanings anyway, so I'm going to explain it from my understanding.

  1. An HTML page is not the destination of a URL.

    Usually, when you type a URL in your browser, you get back an HTML page. What REST says is that the URL1 is just a name. A name for some abstract thing. Now, that thing can have a representation in HTML, or as a picture, or in any other format.

  2. A URL names a resource

    This is any abstract thing.

  3. An HTML page represents that resource

    For the user to see what you're talking about, when they make a GET request on a resource, your server returns an HTML page to "represent" (act as an ambassador for, present in a different form than a URL,..) the resource. A jpeg image, PDF, or a podcast could as easily represent a resource if appropriate.

  4. A row in a database can also represent that resource

    Though a database row can't be passed easily over the wire, so we send other represenations instead.

Transforming database rows into html pages

That leaves us with the fact that a dynamic page is about transforming a database row representation (as identified by a URL) into an html page. For simple and straightforward mappings, this is just a matter of retrieving the row from the database and plugging its values into your template. Ante has this as one of its samples.

But, what happens when you have a more interesting and complicated database where some of the columns in the row are foreign keys to other tables? And some of the logical information about the resource is multivalued and so stored in an auxilary table with a foreign key linking back to this table? And, related to that, what about subparts, such as the lineitems in an purchase order (to use the old example)?

It was in an effort to simplify those kinds of pages and data representations that I created Rior. Rior and a template engine (like Ante) become a representation transforming library. Rior, can then be used with other template engines to create representations in other formats, such as XML, Javascript, or PDF.

As of Jan 2009, I'm still working on making Rior easy to use. I have a proof of concept written, but hard to configure, and it is used like this:

  1. Design your database.
  2. Describe it to Rior.
  3. Pass to Rior your database info (log in info, etc) and which table and row(s) this page is referring to.
  4. Rior will pass back an object that you can pass to Ante to render.
  5. *mod1* This includes giving a select query to Rior at startup.
  6. Ante can then call into that object in a structured way to retrieve rows from various tables as they relate to the row(s) you originally specified.

That list shouldn't change much in future versions of Rior. What should change is how to describe the data to Rior. As of Jan 2009, it's described in an XML like file, with specific indexes (primary, columns, refs, defaults).

Footnotes

  1. or URI or URN, I'm using the name URL since I'm using URLs, but you could use any URI such as a URN, or just use URLs like I do.