diff --git a/docs/topics/django.rst b/docs/topics/django.rst index 67a3fbc84bc..b71615fc561 100644 --- a/docs/topics/django.rst +++ b/docs/topics/django.rst @@ -23,62 +23,22 @@ jump into some other part that interests you. My awesomebar loves these pages: I'm not going to go into detail on anything that's covered in the docs, since they do it better. -Multiple Databases ------------------- -At this point, most people get by running Django apps with one database. Crazy, -I know! The good news: there was a Summer of Code project this year to add -multiple-database support. The bad news: it hasn't been merged with Django yet, -but is a high priority in the -`1.2 release `_ (scheduled -for March 9, 2010). At first I was leaning towards us running the mutlti-db -branch from http://github.com/alex/django/tree/multiple-db, but I'm hesitant -because we'd miss out on other fixes going on in trunk code right now. We could -do our own branch management, but I don't know how much time that would take. - -Since the multi-db branch just provides a better low-level API, we'll have to -roll our own master-slave logic anyways, most likely using Django's -:class:`Managers `. There's some prior art at -http://github.com/mmalone/django-multidb/. Given this, I don't think we'd gain -a lot by running off the github multi-db branch. - - -Working off Trunk --------------------- - -It's pretty common to use /trunk rather than a standard release in the Django -community. The Django developers are very sensitive about breaking -backwards compatibility, and are cautious about what goes into trunk, so it's a -relatively safe option. Since pip lets us pin a git requirement to a certain -hash, we'll all still be running the same Django version, and we won't ever hit -big hurdles upgrading to the next major release. Test also help here, a lot. - -I (jbalogh) am offering to manage upgrades and any breakages. I'll probably -move the Django pointer in between our releases so it's not constantly -disruptive, and we'll have a full QA cycle to make sure everything still works. - - -Migrations ----------- +CSRF +---- -We're going to use `South `_. Here's the -`Quick Start Guide `_, the -`tutorial `__, and the rest of the -`South docs `_. +In Django 1.2, `csrf `_ +was improved by embedding ``{% csrf_token %}`` inside forms instead of using +middleware to rewrite HTML strings. But since we're using Jinja for templating, +that doesn't work. -CSRF ----- +Instead, use :: -The standard version of CSRF in Django used to be middleware that rewrote any -forms it could find in your HTML content to include a hidden token. That's -going away now. + {{ csrf() }} -Details on the new version can be found at -http://docs.djangoproject.com/en/dev/ref/contrib/csrf/. I'll have to write -something to make the ``{% csrf_token %}`` tag work with our Jinja templates, -but the rest will be the same. It will probably look like -``{% csrf_token() %}``. +inside templates to embed the CSRF token Django expects. See +:src:`apps/admin/templates/admin/flagged_addon_list.html` for an example. Testing @@ -90,12 +50,7 @@ http://docs.djangoproject.com/en/dev/topics/testing/ Don't bother with the doctests stuff, we won't use those. We'll write lots of unit tests and make heavy use of the :mod:`test client `. -We're going to use -`nose ` for test -discovery and running. It provides a lot of options like running only the -failing tests and outputting XUnit-style XML (which is cool if you want to -Hudson to understand your test results). Here's a nice app to integrate -nose with Django: http://github.com/jbalogh/django-nose. +See more in :ref:`testing`. Best Practices @@ -117,3 +72,12 @@ it to ``INSTALLED_APPS`` so Django loads the model and Jinja loads the template extensions. You can find lots of goodies on http://www.b-list.org/weblog/categories/django/. + + +Migrations +---------- + +We're going to use `South `_. Here's the +`Quick Start Guide `_, the +`tutorial `__, and the rest of the +`South docs `_.