This works with `Django 1.0.0` and later. It sets the `request.urlconf` variable to an alternate urlconf, if there's a match to the hostname in `settings.MULTIHOST_URLCONF_MAP`
After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class. You could, for example, extend View to be JinjaView, just replacing render_template(). A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
Jinja2, while a great replacement for Django templates, is not a drop-in replacement for it. I wanted to use Photologue with my Jinja templates, but because Photologue uses Django generics, so I decided to see if I could use Jinja2 with generics, and then only modify the templates. It was a bit of work, but I seem to have done it. Django generics can take template_loader as an option, so if you have the same interface, things should just work. The template must accept RequestContext as an argument to render(), so here we subclass jinja2.Template and when it receives Django's RequestContext object, it creates a flat dictionary from it, which jinja2 can work with.
This snippet allows you to use @mako("templatename.mako") to define a mako template to use. Your python method just has to return a dictionary that will be passed to mako's context, after the addition of the "request" variable to the dictionary. If you return a non-False non dictionary object, it will return that instead of trying to render the template. The **request** variable is automatically added to the template's context. It also searches the current application's mako_templates/ subdirectory first before searching under the current directories mako_templates/, and does not use other application's mako_templates/ subdirectories at all. On Mako exceptions, it will display the Mako error page when debugging is enabled (hoping for extensible exception handling in the future to keep consistency) I got the idea from a [CherryPy tool](http://tools.cherrypy.org/wiki/Mako).
If you try to load a template named filename.LANG.html it will try to load filename.de.html first, then filename.html afterwards (assuming that German is the currently selected language). Usage: Put in a file named langtemplateloader.py under your project, and replace django's default filesystem loader with this in the TEMPLATE_LOADERS section of settings.py: TEMPLATE_LOADERS = ( 'myproject.langtemplateloader.load_template_source', # 'django.template.loaders.filesystem.load_template_source', 'django.template.loaders.app_directories.load_template_source', 'django.template.loaders.eggs.load_template_source', )