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 middleware will put the sessionid in every place that it might be needed, I mean, as a hidden input in every form, at the end of the document as a javascrit variable to allow the AJAX request use it and of course as a GET variable of the request.
To make it work correctly the MIDDLEWARE_CLASSES tuple must be in this order:
`
'CookielessSessionPreMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'CookielessSessionPosMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
`
Hope it work for someone else out there.
- middleware
- cookie
- cookieless
- less
This was a wild experiment, which appears to work!
One model holds all the data, from every object version ever to exist. The other model simply points to the latest object from its gigantic brother. All fields can be accessed transparently from the little model version, so the user need not know what is going on. Coincidently, Django model inheritance does exactly the same thing, so to keep things insanely simple, that's what we'll use:
class EmployeeHistory(FullHistory):
name = models.CharField(max_length=100)
class Employee(EmployeeHistory):
pass
That's it! Django admin can be used to administer the `Employee` and every version will be kept as its own `EmployeeHistory` object, these can of course all be browsed using the admin :-)
This is early days and just a proof of concept. I'd like to see how far I can go with this, handling `ForeignKey`s, `ManyToManyField`s, using custom managers and so on. It should all be straightforward, especially as the primary keys should be pretty static in the history objects...
*updated 3 August 2009 for Django 1.1 and working date_updated fields*