So you’ve read all the introductory material and have decided you’d like to keep using Django. We’ve only just scratched the surface with this intro (in fact, if you’ve read every single word you’ve still read less than 10% of the overall documentation).
So what’s next?
Well, we’ve always been big fans of learning by doing. At this point you should know enough to start a project of your own and start fooling around. As you need to learn new tricks, come back to the documentation.
We’ve put a lot of effort into making Django’s documentation useful, easy to read and as complete as possible. The rest of this document explains more about how the documentation works so that you can get the most out of it.
(Yes, this is documentation about documentation. Rest assured we have no plans to write a document about how to read the document about documentation.)
Django’s got a lot of documentation – almost 200,000 words – so finding what you need can sometimes be tricky. A few good places to start are the Search Page and the Index.
Or you can just browse around!
Django’s main documentation is broken up into “chunks” designed to fill different needs:
The introductory material is designed for people new to Django – or to Web development in general. It doesn’t cover anything in depth, but instead gives a high-level overview of how developing in Django “feels”.
The topic guides, on the other hand, dive deep into individual parts of Django. There are complete guides to Django’s model system, template engine, forms framework, and much more.
This is probably where you’ll want to spend most of your time; if you work your way through these guides you should come out knowing pretty much everything there is to know about Django.
Web development is often broad, not deep – problems span many domains. We’ve written a set of how-to guides that answer common “How do I ...?” questions. Here you’ll find information about generating PDFs with Django, writing custom template tags, and more.
Answers to really common questions can also be found in the FAQ.
The guides and how-to’s don’t cover every single class, function, and method available in Django – that would be overwhelming when you’re trying to learn. Instead, details about individual classes, functions, methods, and modules are kept in the reference. This is where you’ll turn to find the details of a particular function or whathaveyou.
Finally, there’s some “specialized” documentation not usually relevant to most developers. This includes the release notes, documentation of obsolete features, internals documentation for those who want to add code to Django itself, and a few other things that simply don’t fit elsewhere.
Just as the Django code base is developed and improved on a daily basis, our documentation is consistently improving. We improve documentation for several reasons:
Django’s documentation is kept in the same source control system as its code. It lives in the django/trunk/docs directory of our Subversion repository. Each document online is a separate text file in the repository.
You can read Django documentation in several ways. They are, in order of preference:
The most recent version of the Django documentation lives at http://docs.djangoproject.com/en/dev/. These HTML pages are generated automatically from the text files in source control. That means they reflect the “latest and greatest” in Django – they include the very latest corrections and additions, and they discuss the latest Django features, which may only be available to users of the Django development version. (See “Differences between versions” below.)
We encourage you to help improve the docs by submitting changes, corrections and suggestions in the ticket system. The Django developers actively monitor the ticket system and use your feedback to improve the documentation for everybody.
Note, however, that tickets should explicitly relate to the documentation, rather than asking broad tech-support questions. If you need help with your particular Django setup, try the django-users mailing list or the #django IRC channel instead.
For offline reading, or just for convenience, you can read the Django documentation in plain text.
If you’re using an official release of Django, note that the zipped package (tarball) of the code includes a docs/ directory, which contains all the documentation for that release.
If you’re using the development version of Django (aka the Subversion “trunk”), note that the docs/ directory contains all of the documentation. You can svn update it, just as you svn update the Python code, in order to get the latest changes.
You can check out the latest Django documentation from Subversion using this shell command:
$ svn co http://code.djangoproject.com/svn/django/trunk/docs/ django_docs
One low-tech way of taking advantage of the text documentation is by using the Unix grep utility to search for a phrase in all of the documentation. For example, this will show you each mention of the phrase "max_length" in any Django document:
$ grep -r max_length /path/to/django/docs/
You can get a local copy of the HTML documentation following a few easy steps:
Django's documentation uses a system called Sphinx to convert from plain text to HTML. You'll need to install Sphinx by either downloading and installing the package from the Sphinx Web site, or by Python's easy_install:
$ easy_install Sphinx
Then, just use the included Makefile to turn the documentation into HTML:
$ cd path/to/django/docs
$ make html
You'll need GNU Make installed for this.
The HTML documentation will be placed in docs/_build/html.
Note
Generation of the Django documentation will work with Sphinx version 0.6 or newer, but we recommend going straight to Sphinx 1.0.2 or newer.
As previously mentioned, the text documentation in our Subversion repository contains the "latest and greatest" changes and additions. These changes often include documentation of new features added in the Django development version -- the Subversion ("trunk") version of Django. For that reason, it's worth pointing out our policy on keeping straight the documentation for various versions of the framework.
We follow this policy:
Dec 26, 2011