MickBlog: wsgi

Insane plan number 1

Posted 2007-09-02 1:08 p.m. by mick. 2 comments so far.

I've been thinking of rewriting my site's code for a while. Apart from the fact I've neglected the code base a bit and I'm too lazy to bring it into Django's post magic removal age, it's always fun to rewrite personal projects. Particularly if they aren't important to a company, you can hack away with aplomb. It's also good for keeping my interest in the site, I find the amount of useful articles I write is proportional to how much code I'm writing in the background.

So, how am I rewriting it? My crazy plan at the moment is to go python old school and write my own site framework! It's not as bad as it sounds, I'm using mako for the templates, I'm using webob for the request/response objects (this actually covers 99% of the fiddly bits in a framework in my opinion), probably SQLAlchemy for storage (though I might play with a non-SQL approach) and my own custom url dispatcher modelled very closely on django's regex pattern system.

The latter is the only real custom code I need to write, and at the moment it's a teeny bit of code. Ironically, with the adoption of WSGI to unite web frameworks, and the move towards consolidating on a few frameworks has opened up the possibility of writing your own custom site using off the shelf components. I think this is a good thing, I suspect I'll only have a few hundred lines of custom code at most, and this will give me a site which works exactly the way I want it to.

For example, I'm adding method arguments to the url dispatcher, so I can say (r'/articles/add', mysite.article_add_form, methods=["GET"]) and (r'/articles/add', mysite.article_add, methods=["POST"]) to handle two completely different actions without having a fiddly if/else in my code.

With doctest and nose I've got a bunch of tests which are pretty sweet too, no mucking about with funny classes.

All in all, it's a good time to be a unorthodox developer, with so many good components to choose from, and increasingly standard ways to glue them together without losing your sanity, it's fun to write your own web framework again :)

Using commentary with django

Posted 2006-03-02 4:17 p.m. by mick. 3 comments so far.

tags: django python wsgi

This is a real simple example of using Ian Bicking's Commentary paste filter with a Django site. This, to me, illustrates the power of WSGI, I've taken someone's web framework (Django) and plugged in a powerful commenting system (Commentary) without any changes to the framework what so ever.

import os
os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"

import django.conf.settings

from django.core.servers.basehttp import AdminMediaHandler
from django.core.handlers.wsgi import WSGIHandler

from commentary.wsgiapp import make_app_filter

if __name__ == "__main__":
    app = AdminMediaHandler(WSGIHandler())
    app = make_app_filter(app, dict(
        storage = "/tmp/$path_info_dir/$path_info_base.comments.txt",
        body_start_re = "<body>",
        body_end_re = "</body>",
        input_encoding = "UTF-8",
        next = "docs",
    ))
    from paste import httpserver
    httpserver.serve(app, host='127.0.0.1', port='8080')

As you can see it's just a question of creating the app, then the filter (or filters) and then starting the site using your preferred server. It's even easier using paste (though I haven't tried using paste and django together).

Note that I pretty much just followed this guide.

Update

I've changed the ISO-8859-1 to UTF-8 'cos of Radek's comment. It was just an oversight on my part. However I don't recommend changing the codeset to UTF-8 without checking to see what your site is encoded in. Odd things can happen. Just today I had a problem with psycopg1 coredumping due to its endearing trait of barfing on non-ascii strings. Turns out some 1252 had crept in even from an external tool claiming its output is UTF-8.