Within this section, the reader will find a broad overview of WebPython (written so as to be intelligible to a novice web programmer) and the story of how this toolkit came to be. For those readers who have web-application experience, feel free to skip the overview (except, perhaps, for the first paragraph, which outlines the component modules of WebPython).

1.1.1 The Description

WebPython is a web-application development toolkit, written (of course) in Python. It consists of a document templating system, a light-weight remote procedure call system (which uses Python, rather than, say, XML), simple project management tools, date conversion utilities, an object-relational database interface, and a Python-object persistence system.

But what does all this mean? What purpose does it serve, and why is it needed? Let's break it down.

The document templating system is, quite simply, a way to separate the presentation layer of an application (a web page, for instance) from the actual code of the application. In other words, one would simply create a template (web page, in this case) and add variables within it. Then, in the program code, the programmer would initialize the templating system, register values for the variables declared in the template, and then display the template. So the end product would be a web page with program-specified values (like text) within it.

This is of limited use for very small documents and programs, but is a real life-saver when working on large projects. A project team could have a graphic designer create a template for a document, then have programmers write the program to fill in the content. And the template could change, without the program having to.

The remote-procedure call (RPC) mechanism (PyRPC) enables clients to communicate with (and execute code inside of) a server application. This is of interest in web applications primarily because it enables a much greater degree of interactivity than standard methods of communication. Basically, the traditional method to load data into a web application is to reload the relevant page, supplying the new data. But with RPC, one can simply use JavaScript controls within the web browser (on the client side) to communicate with the server, get the new data, and then refresh only a very specific portion of the page. This, obviously, leads to a much more responsive application.

In terms of web services (which very simply defined are bits of software running on a remote server, supplying data manipulated by a generic client) RPC has even greater import, namely the fact that it is the one of a very few ways in which server and client can communicate.

What makes PyRPC special is that it uses a Python dictionary (an associative array) to send (and receive) messages, rather than other formats, of which XML is usually the preferred choice. This has the effect of eliminating the need for a parser, simply reading values from the dictionary and acting accordingly. This makes the PyRPC protocol much lighter-weight.

The project management tools are very simple indeed, just a way of automating directory creation and web server configuration. The date conversion utilities are almost as simple, converting dates between formats (for example, "1/2/03" to "02 Jan 2003").

The object-relational database interface is one of the most important parts of WebPython. In essence, when initialized by a program, it connects to a given database and builds a class-hierarchy around its properties (for instance, the database object would have a sub-object for each table in the database, and each table object would have a dictionary representing its fields and their properties). This access model makes it effortless to manipulate databases from within Python, all without needing to use SQL.

The persistence system is a set of functions to store a Python object into a specified table of a certain format, load an object from a specified table, and, if ordered to, delete said object. This is useful for storing information (say, about users of a web site) in the mid- to long-term, without needing to convert it into a table-friendly format on storing and then back into a Python object on loading. The only drawback is that the given table must be of a very specific format (covered in the reference, naturally).

So basically, rather than providing a framework within which an application developer must work to build their application, WebPython provides a set of tools (hence "toolkit") that give the developer open-ended possibilities. One uses WebPython in one's application; one's application does not run in or on WebPython.

1.1.2 The Story

Why a web-application toolkit? In Python, no less? Well, I wanted to write a small interactive web program (an amateur astronomy logbook, actually) and, being familiar with Python, I wanted some way to easily use it for my program. I had previously used mod_python for other small projects, but mod_python is very low-level; it gives the developer an interpreter embedded in an Apache server, a way to map functions to URLs, an HTTP request object, and a few other basics. I was looking for something more high-level; something that would encompass database access and remote procedure calls easily.

I looked around at my options. I found an excellent application server (Zope) but my program didn't warrant the complexities of such a server. It was just a small logbook, and all I wanted was to avoid SQL and have some RPC mechanism available to me.

I also found frameworks galore, and a few collection of modules (still in their infancy) but nothing that was both useable and not too over-engineered. Because that was the problem, every technology seemed to be centered around the idea of a framework; there weren't many simple tools, tools that I could use in my application without buying into overly-complex configuration files and rigid database access.

But then I had a thought. What if a toolkit (of sorts) could be built over a low-level interface, such as mod_python? I determined that I had at least a chance of being succesful with such a project, and promptly tried.

As I wrote my logbook application, my toolkit grew. I needed database access; I added a light-weight object-relational mapper. I needed portability between databases; I abstracted the mapper API. RPC? I wrote a simple class that used Apache as its server. Persistence? I added a persistence API to my database layer. And so on.

Before I knew it, I had a near-complete web-app toolkit on my hands (plus a logbook program). With a little bit of polish (adding joins to the database routines, cleaning up PyRPC) I could release it to the public at large. And so, WebPython is the result.

It's not complete, of course; there are other features which I could think to add. But the mantra of open source is "release early, release often," and do so I shall. Saving new features for future releases, naturally.