Hi Simon,
> 1. SafeForm has no dependency on Django's session framework. This is A
> Good Thing as I personally avoid sessions in my projects (no need to
> access state on every request if you can get away with not doing it).
...
> It's a bit more than that - I also want something that works
> independently of sessions, middleware and RequestContext, but that's
> mainly due to my own personal Django development preference.
Just one thing to say in reply - the new version of CsrfViewMiddleware is also
independent of sessions. It sets its own cookie just like SafeForm does.
The references to the session framework still in there are purely for
backwards compatibility -- if a form is created and sent to the user with
Django 1.1, and the site is then upgraded to 1.2, when the user submits the
form the request will have a session cookie and a CSRF token, but no CSRF
cookie, which would produce a 403 error. So for that tiny little window, we
allow a fall-back to using the 1.1 method by allowing a session cookie for a
CSRF cookie. The fall-back doesn't actually trigger any session activity - it
just looks at request.COOKIES[settings.SESSION_COOKIE_NAME].
I also had one thing to add to my previous e-mail - on the backwards
compatibility front, there are also the tests that people may have written
against customised contrib views. I have examples of these in my projects --
where I have added significant customisations to the admin, and I want to test
certain post-conditions etc. In these cases, we also have potential for
breakage - the tests are going to fail until they are updated in the same way
that core tests need to be updated to get and use the CSRF token. This will
happen even if people have used 'best practice' (using super() and inheritance
so they don't duplicate any actual contrib code or templates). The examples I
have in my code actually would not break, because I happen to have used twill
for those tests, but I think the point stands. (You could argue that 'best
practice' for tests means using twill-like tests, but Django tests have not
provided either a good example or helpful utilities on this front, so it's an
unreasonable expectation IMO).
Broken tests are not as bad as breaking the actual site, but any responsible
developer is going to fix rather than ignore failing tests, so it definitely
adds to the upgrade cost.
Regards, and thanks for taking my (lengthy) criticisms in good spirit!
Luke
--
OSBORN'S LAW
Variables won't, constants aren't.
Luke Plant || http://lukeplant.me.uk/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
