Quixote: a Python-Centric Web Application Framework

If you need to create dynamic web sites and don't want to learn the syntax and arbitrary limitations of yet another templating language, you should give Quixote a serious look.
Connecting Your Web Server to Your Quixote Application

Every Quixote application needs a bit of glue to to connect the web server to the application; the nature of this glue depends on the nature of the connection. The simplest way to connect a web server to a Quixote application is CGI, in which case you need to supply a CGI driver script for your application. The CGI driver script for SPLAT! (which, incidentally, also works with FastCGI) looks something like this:

1.#!/usr/bin/python
2.
3. from quixote import enable_ptl, Publisher
4. from splat.config import OptionParser, get_config
5.
6. enable_ptl()
7. config = get_config()
8. config.read_file("/www/conf/splat.conf")
9. pub = Publisher("splat.web", config=config)
10. pub.setup_logs()
11. pub.publish_cgi()

The call to enable_ptl() in line 6 installs an import hook that makes Python's import statement treat PTL modules the same as Python modules. It only has to be done once in each Python process, so the driver script is the obvious place to do it.

Lines 7 and 8 create a standard SPLAT! configuration object and customize it by reading a local configuration file. (In reality, it's more complex than this because SPLAT! has several auxiliary command-line scripts that need to read the same config file.) Most Quixote applications will want to do something like this in order to customize Quixote's behaviour. In particular, Quixote's default settings prefer security and performance over ease of debugging, so for developing new applications, it's useful to override them by reading a local config file. The demo provided with Quixote has a simple example of doing this.

Line 9 is where we finally establish that the web interface for SPLAT! is implemented by the splat.web package. Every Quixote application is centered around an instance of the Publisher class, which is where all of Quixote's URL interpretation is done. Because this object needs to know the root namespace of your application, it is passed to the Publisher constructor as shown.

Every Quixote application can have up to three log files: the error log, the debug log and the access log. The names of these log files are specified via the configuration object passed to Publisher's constructor (they are a good thing to put in your local configuration file), but you need to call setup_logs(), as shown in line 10, to make sure the log files are actually opened and written to. Every HTTP request processed by Quixote is logged in the access log; every string written to sys.stdout is written to the debug log; and every string written to sys.stderr goes to the error log. This means that instrumenting a Quixote application for debugging is as simple as adding print statements.

Finally, in line 11, we pass control over to Quixote. If this driver script is used as a CGI script, then this whole process will repeat for every HTTP request; if it is handled as a FastCGI script, then the process_cgi() method will process requests as long as the web server keeps the script running.

At this point, you can install the driver script wherever your web server is configured to look for CGI scripts, e.g., with the standard Debian Apache package, you would put it in /usr/lib/cgi-bin. Now you can access SPLAT! via a URL like /cgi-bin/splat.cgi/, which will work but is rather ugly and exposes a lot of implementation details. If you use Apache with the rewrite engine enabled, it's trivial to add a rule that rewrites /bugs/ to /cgi-bin/splat.cgi/, so end users never have to see that ugly, over-informative URL. See doc/web-server.txt in the Quixote source distribution for more information.

Availability (and More Sample Code)

Quixote is available from www.mems-exchange.org/software/quixote. You can download the latest source distribution (the current version as of this writing is 0.5), browse the documentation, join the quixote-users@mems-exchange.org mailing list or browse the mailing list archive.

Installation instructions can be found on the web site and also are included in the source distribution, in doc/INSTALL.

The Quixote demo, included in the source distribution, is a much simpler example application than SPLAT!. The documentation for the Quixote demo goes over the code in great detail, explaining most of Quixote's important principles along the way.

You'll also find documentation for some interesting Quixote features I haven't covered here, notably Quixote's session management interface and its HTML form/widget library. Session management lets you maintain server-side information about individual users of your site via a session cookie, which has all sorts of useful applications for dynamic web sites. Quixote's form/widget library makes constructing and processing complex web forms (still the only portable, reliable way to interact with users over the web) much easier. Like the rest of Quixote, it wraps an object-oriented Python interface around a common web programming task.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

quixote wiki link

charter97's picture

welcome to quixote.ca