diff options
| author | Robin Munn <robin.munn@gmail.com> | 2007-01-31 23:43:09 +0000 |
|---|---|---|
| committer | Robin Munn <robin.munn@gmail.com> | 2007-01-31 23:43:09 +0000 |
| commit | fe361e678a46dc4c717c79c2f12b3ba32293b81a (patch) | |
| tree | 8f42488e7d95244bab3db7b2bf934e006940521a /docs | |
| parent | 122426e7453ed638a0c5be7e8b925adcddea3889 (diff) | |
Merged revisions 4186 to 4454 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/sqlalchemy@4455 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs')
42 files changed, 1341 insertions, 318 deletions
diff --git a/docs/add_ons.txt b/docs/add_ons.txt index 58c01c4fc0..d937eb2141 100644 --- a/docs/add_ons.txt +++ b/docs/add_ons.txt @@ -17,7 +17,7 @@ admin The automatic Django administrative interface. For more information, see `Tutorial 2`_. -.. _Tutorial 2: http://www.djangoproject.com/documentation/tutorial2/ +.. _Tutorial 2: ../tutorial2/ auth ==== @@ -26,7 +26,7 @@ Django's authentication framework. See the `authentication documentation`_. -.. _authentication documentation: http://www.djangoproject.com/documentation/authentication/ +.. _authentication documentation: ../authentication/ comments ======== @@ -46,7 +46,7 @@ A middleware for preventing Cross Site Request Forgeries See the `csrf documentation`_. -.. _csrf documentation: http://www.djangoproject.com/documentation/csrf/ +.. _csrf documentation: ../csrf/ formtools ========= @@ -137,7 +137,7 @@ A framework for managing simple "flat" HTML content in a database. See the `flatpages documentation`_. -.. _flatpages documentation: http://www.djangoproject.com/documentation/flatpages/ +.. _flatpages documentation: ../flatpages/ markup ====== @@ -157,7 +157,7 @@ A framework for managing redirects. See the `redirects documentation`_. -.. _redirects documentation: http://www.djangoproject.com/documentation/redirects/ +.. _redirects documentation: ../redirects/ sites ===== @@ -168,7 +168,7 @@ one or more sites. See the `sites documentation`_. -.. _sites documentation: http://www.djangoproject.com/documentation/sites/ +.. _sites documentation: ../sites/ sitemaps ======== @@ -177,7 +177,7 @@ A framework for generating Google sitemap XML files. See the `sitemaps documentation`_. -.. _sitemaps documentation: http://www.djangoproject.com/documentation/sitemaps/ +.. _sitemaps documentation: ../sitemaps/ syndication =========== @@ -186,7 +186,7 @@ A framework for generating syndication feeds, in RSS and Atom, quite easily. See the `syndication documentation`_. -.. _syndication documentation: http://www.djangoproject.com/documentation/syndication/ +.. _syndication documentation: ../syndication/ Other add-ons ============= diff --git a/docs/apache_auth.txt b/docs/apache_auth.txt index b85057924b..583cb96b39 100644 --- a/docs/apache_auth.txt +++ b/docs/apache_auth.txt @@ -65,7 +65,7 @@ are equivalent:: SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonOption DJANGO_SETTINGS_MODULE mysite.settings -.. _authentication system: http://www.djangoproject.com/documentation/authentication/ +.. _authentication system: ../authentication/ .. _Subversion: http://subversion.tigris.org/ .. _mod_dav: http://httpd.apache.org/docs/2.0/mod/mod_dav.html -.. _custom permissions: http://www.djangoproject.com/documentation/authentication/#custom-permissions +.. _custom permissions: ../authentication/#custom-permissions diff --git a/docs/api_stability.txt b/docs/api_stability.txt index 18885fbe63..508336e0ef 100644 --- a/docs/api_stability.txt +++ b/docs/api_stability.txt @@ -98,26 +98,26 @@ change: rewrite before Django 1.0. Even if the change isn't quite that drastic, there will at least be moderate changes. -.. _caching: http://www.djangoproject.com/documentation/cache/ -.. _custom template tags and libraries: http://www.djangoproject.com/documentation/templates_python/ -.. _database lookup: http://www.djangoproject.com/documentation/db_api/ -.. _django-admin utility: http://www.djangoproject.com/documentation/django_admin/ -.. _fastcgi integration: http://www.djangoproject.com/documentation/fastcgi/ -.. _flatpages: http://www.djangoproject.com/documentation/flatpages/ -.. _generic views: http://www.djangoproject.com/documentation/generic_views/ -.. _internationalization: http://www.djangoproject.com/documentation/i18n/ -.. _legacy database integration: http://www.djangoproject.com/documentation/legacy_databases/ -.. _model definition: http://www.djangoproject.com/documentation/model_api/ -.. _mod_python integration: http://www.djangoproject.com/documentation/modpython/ -.. _redirects: http://www.djangoproject.com/documentation/redirects/ -.. _request/response objects: http://www.djangoproject.com/documentation/request_response/ -.. _sending email: http://www.djangoproject.com/documentation/email/ -.. _sessions: http://www.djangoproject.com/documentation/sessions/ -.. _settings: http://www.djangoproject.com/documentation/settings/ -.. _syndication: http://www.djangoproject.com/documentation/syndication/ -.. _template language: http://www.djangoproject.com/documentation/templates/ -.. _transactions: http://www.djangoproject.com/documentation/transactions/ -.. _url dispatch: http://www.djangoproject.com/documentation/url_dispatch/ -.. _forms and validation: http://www.djangoproject.com/documentation/forms/ -.. _serialization: http://www.djangoproject.com/documentation/serialization/ -.. _authentication: http://www.djangoproject.com/documentation/authentication/ +.. _caching: ../cache/ +.. _custom template tags and libraries: ../templates_python/ +.. _database lookup: ../db_api/ +.. _django-admin utility: ../django_admin/ +.. _fastcgi integration: ../fastcgi/ +.. _flatpages: ../flatpages/ +.. _generic views: ../generic_views/ +.. _internationalization: ../i18n/ +.. _legacy database integration: ../legacy_databases/ +.. _model definition: ../model_api/ +.. _mod_python integration: ../modpython/ +.. _redirects: ../redirects/ +.. _request/response objects: ../request_response/ +.. _sending email: ../email/ +.. _sessions: ../sessions/ +.. _settings: ../settings/ +.. _syndication: ../syndication/ +.. _template language: ../templates/ +.. _transactions: ../transactions/ +.. _url dispatch: ../url_dispatch/ +.. _forms and validation: ../forms/ +.. _serialization: ../serialization/ +.. _authentication: ../authentication/ diff --git a/docs/authentication.txt b/docs/authentication.txt index 08565e13e1..ef30879ae0 100644 --- a/docs/authentication.txt +++ b/docs/authentication.txt @@ -144,8 +144,8 @@ custom methods: Raises ``django.contrib.auth.models.SiteProfileNotAvailable`` if the current site doesn't allow profiles. -.. _Django model: http://www.djangoproject.com/documentation/model_api/ -.. _DEFAULT_FROM_EMAIL: http://www.djangoproject.com/documentation/settings/#default-from-email +.. _Django model: ../model_api/ +.. _DEFAULT_FROM_EMAIL: ../settings/#default-from-email Manager functions ~~~~~~~~~~~~~~~~~ @@ -271,8 +271,8 @@ previous section). You can tell them apart with ``is_authenticated()``, like so: else: # Do something for anonymous users. -.. _request objects: http://www.djangoproject.com/documentation/request_response/#httprequest-objects -.. _session documentation: http://www.djangoproject.com/documentation/sessions/ +.. _request objects: ../request_response/#httprequest-objects +.. _session documentation: ../sessions/ How to log a user in -------------------- @@ -441,8 +441,8 @@ block:: {% endblock %} -.. _forms documentation: http://www.djangoproject.com/documentation/forms/ -.. _site framework docs: http://www.djangoproject.com/documentation/sites/ +.. _forms documentation: ../forms/ +.. _site framework docs: ../sites/ Limiting access to logged-in users that pass a test --------------------------------------------------- @@ -544,7 +544,7 @@ For example:: def limited_object_detail(*args, **kwargs): return object_detail(*args, **kwargs) -.. _generic view: http://www.djangoproject.com/documentation/generic_views/ +.. _generic view: ../generic_views/ Permissions =========== @@ -606,7 +606,7 @@ This example model creates three custom permissions:: The only thing this does is create those extra permissions when you run ``syncdb``. -.. _model Meta attribute: http://www.djangoproject.com/documentation/model_api/#meta-options +.. _model Meta attribute: ../model_api/#meta-options API reference ------------- @@ -645,7 +645,7 @@ The currently logged-in user and his/her permissions are made available in the setting contains ``"django.core.context_processors.auth"``, which is default. For more, see the `RequestContext docs`_. - .. _RequestContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext + .. _RequestContext docs: ../templates_python/#subclassing-context-requestcontext Users ----- @@ -691,7 +691,7 @@ Thus, you can check permissions in template ``{% if %}`` statements:: <p>You don't have permission to do anything in the foo app.</p> {% endif %} -.. _template context: http://www.djangoproject.com/documentation/templates_python/ +.. _template context: ../templates_python/ Groups ====== @@ -756,7 +756,7 @@ scenes, so any messages will be deleted even if you don't display them. Finally, note that this messages framework only works with users in the user database. To send messages to anonymous users, use the `session framework`_. -.. _session framework: http://www.djangoproject.com/documentation/sessions/ +.. _session framework: ../sessions/ Other authentication sources ============================ diff --git a/docs/cache.txt b/docs/cache.txt index 1795345ed9..054d99819d 100644 --- a/docs/cache.txt +++ b/docs/cache.txt @@ -250,7 +250,7 @@ Additionally, ``CacheMiddleware`` automatically sets a few headers in each See the `middleware documentation`_ for more on middleware. -.. _`middleware documentation`: http://www.djangoproject.com/documentation/middleware/ +.. _`middleware documentation`: ../middleware/ The per-view cache ================== diff --git a/docs/contributing.txt b/docs/contributing.txt index 6ff0b038a3..d802d3eaf6 100644 --- a/docs/contributing.txt +++ b/docs/contributing.txt @@ -22,6 +22,9 @@ of the community, so there are many ways you can help Django's development: likely to be skeptical of large-scale suggestions without some code to back it up. + * Triage patches that have been submitted by other users. Please read + `Ticket triage`_ below, for details on the triage process. + That's all you need to know if you'd like to join the Django development community. The rest of this document describes the details of how our community works and how it handles bugs, mailing lists, and all the other minutiae of @@ -44,8 +47,10 @@ particular: * **Do** write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test - cases, etc. A minimal example that illustrates the bug in a nice small - test case is the best possible bug report. + cases, etc. This means including a clear, concise description of the + problem, and a clear set of instructions for replicating the problem. + A minimal example that illustrates the bug in a nice small test case + is the best possible bug report. * **Don't** use the ticket system to ask support questions. Use the `django-users`_ list, or the `#django`_ IRC channel for that. @@ -117,9 +122,99 @@ Patch style * Name the patch file with a ``.diff`` extension; this will let the ticket tracker apply correct syntax highlighting, which is quite helpful. - * Put the prefix "[patch] " before the title of your ticket. This will make - it obvious that the ticket includes a patch, and it will add the ticket - to the `list of tickets with patches`_. + * Check the "Has patch" box on the ticket details. This will make it + obvious that the ticket includes a patch, and it will add the ticket to + the `list of tickets with patches`_. + + * The code required to fix a problem or add a feature is an essential part + of a patch, but it is not the only part. A good patch should also include + a regression test to validate the behavior that has been fixed (and prevent + the problem from arising again). + + * If the code associated with a patch adds a new feature, or modifies behavior + of an existing feature, the patch should also contain documentation. + +Non-trivial patches +------------------- + +A "non-trivial" patch is one that is more than a simple bug fix. It's a patch +that introduces Django functionality and makes some sort of design decision. + +If you provide a non-trivial patch, include evidence that alternatives have +been discussed on `django-developers`_. If you're not sure whether your patch +should be considered non-trivial, just ask. + +Ticket triage +============= + +Unfortunately, not all bug reports in the `ticket tracker`_ provide all +the `required details`_. A number of tickets have patches, but those patches +don't meet all the requirements of a `good patch`_. + +One way to help out is to *triage* bugs that have been reported by other +users. A couple of dedicated volunteers work on this regularly, but more help +is always appreciated. + +Most of the workflow is based around the concept of a ticket's "triage stage". +This stage describes where in its lifetime a given ticket is at any time. +Along with a handful of flags, this field easily tells us what and who each +ticket is waiting on. + +Since a picture is worth a thousand words, let's start there: + +.. image:: http://media.djangoproject.com/img/doc/djangotickets.png + :height: 451 + :width: 590 + :alt: Django's ticket workflow + +We've got two roles here: + + * Core developers: people with commit access who make the decisions and + write the bulk of the code. + + * Ticket triagers: community members who keep track of tickets, making + sure the tickets are always categorized correctly. + +Second, note the four triage stages: + + 1. A ticket starts as "Unreviewed", meaning that a triager has yet to + examine the ticket and move it along. + + 2. "Design decision needed" means "this concept requires a design + decision," which should be discussed either in the ticket comments or on + django-developers. + + 3. Once a ticket is ruled to be approved for fixing, it's moved into the + "Accepted" stage. This stage is where all the real work gets done. + + 4. If a ticket has an associated patch (see below), a triager will review the + patch. If the patch is complete, it'll be marked as "ready for checkin" so + that a core developer knows to review and check in the patches. + +The second part of this workflow involves a set of flags the describe what the +ticket has or needs in order to be "ready for checkin": + + "Has patch" + The means the ticket has an associated patch_. These will be + reviewed to see if the patch is "good". + + "Needs documentation" + This flag is used for tickets with patches that need associated + documentation. Complete documentation of features is a prerequisite + before we can check a fix into the codebase. + + "Needs tests" + This flags the patch as needing associated unit tests. Again, this is a + required part of a valid patch. + + "Patch needs improvement" + This flag means that although the ticket *has* a patch, it's not quite + ready for checkin. This could mean the patch no longer applies + cleanly, or that the code doesn't live up to our standards. + +.. _required details: `Reporting bugs`_ +.. _good patch: `Patch style`_ +.. _patch: `Submitting patches`_ Submitting and maintaining translations ======================================= @@ -137,7 +232,7 @@ translated, here's what to do: `i18n documentation`_. .. _Django i18n mailing list: http://groups.google.com/group/django-i18n/ -.. _i18n documentation: http://www.djangoproject.com/documentation/i18n/ +.. _i18n documentation: ../i18n/ Coding style ============ @@ -262,7 +357,7 @@ The Django tests all use the testing infrastructure that ships with Django for testing applications. See `Testing Django applications`_ for an explanation of how to write new tests. -.. _Testing Django applications: http://www.djangoproject.com/documentation/testing/ +.. _Testing Django applications: ../testing/ Running the unit tests ---------------------- @@ -338,21 +433,63 @@ trunk more than once. Using branches -------------- -To test a given branch, you can simply check out the entire branch, like so:: +To use a branch, you'll need to do two things: + + * Get the branch's code through Subversion. + + * Point your Python ``site-packages`` directory at the branch's version of + the ``django`` package rather than the version you already have + installed. + +Getting the code from Subversion +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get the latest version of a branch's code, check it out using Subversion:: svn co http://code.djangoproject.com/svn/django/branches/<branch>/ -Or, if you've got a working directory you'd like to switch to use a branch, -you can use:: +...where ``<branch>`` is the branch's name. See the `list of branch names`_. - svn switch http://code.djangoproject.com/svn/django/branches/<branch>/ +Alternatively, you can automatically convert an existing directory of the +Django source code as long as you've checked it out via Subversion. To do the +conversion, execute this command from within your ``django`` directory:: -...in the root of your Django sandbox (the directory that contains ``django``, -``docs``, and ``tests``). + svn switch http://code.djangoproject.com/svn/django/branches/<branch>/ The advantage of using ``svn switch`` instead of ``svn co`` is that the ``switch`` command retains any changes you might have made to your local copy -of the code. It attempts to merge those changes into the "switched" code. +of the code. It attempts to merge those changes into the "switched" code. The +disadvantage is that it may cause conflicts with your local changes if the +"switched" code has altered the same lines of code. + +(Note that if you use ``svn switch``, you don't need to point Python at the new +version, as explained in the next section.) + +.. _list of branch names: http://code.djangoproject.com/browser/django/branches + +Pointing Python at the new Django version +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once you've retrieved the branch's code, you'll need to change your Python +``site-packages`` directory so that it points to the branch version of the +``django`` directory. (The ``site-packages`` directory is somewhere such as +``/usr/lib/python2.4/site-packages`` or +``/usr/local/lib/python2.4/site-packages`` or ``C:\Python\site-packages``.) + +The simplest way to do this is by renaming the old ``django`` directory to +``django.OLD`` and moving the trunk version of the code into the directory +and calling it ``django``. + +Alternatively, you can use a symlink called ``django`` that points to the +location of the branch's ``django`` package. If you want to switch back, just +change the symlink to point to the old code. + +If you're using Django 0.95 or earlier and installed it using +``python setup.py install``, you'll have a directory called something like +``Django-0.95-py2.4.egg`` instead of ``django``. In this case, edit the file +``setuptools.pth`` and remove the line that references the Django ``.egg`` +file. Then copy the branch's version of the ``django`` directory into +``site-packages``. Official releases ================= @@ -457,8 +594,7 @@ requests for commit access are potential flame-war starters, and will be ignored .. _search the tracker: http://code.djangoproject.com/search .. _django-users: http://groups.google.com/group/django-users .. _`#django`: irc://irc.freenode.net/django -.. _list of tickets with patches: http://code.djangoproject.com/report/12 +.. _list of tickets with patches: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=1&order=priority .. _PEP 8: http://www.python.org/peps/pep-0008.html -.. _i18n documentation: http://www.djangoproject.com/documentation/i18n/ .. _i18n branch: http://code.djangoproject.com/browser/django/branches/i18n .. _`tags/releases`: http://code.djangoproject.com/browser/django/tags/releases diff --git a/docs/csrf.txt b/docs/csrf.txt index 218b43a61a..c12dd1d116 100644 --- a/docs/csrf.txt +++ b/docs/csrf.txt @@ -1,9 +1,9 @@ ===================================== -Cross Site Request Forgery Protection +Cross Site Request Forgery protection ===================================== -The CsrfMiddleware class provides easy-to-use protection against -`Cross Site Request Forgeries`_. This type of attack occurs when a malicious +The CsrfMiddleware class provides easy-to-use protection against +`Cross Site Request Forgeries`_. This type of attack occurs when a malicious web site creates a link or form button that is intended to perform some action on your web site, using the credentials of a logged-in user who is tricked into clicking on the link in their browser. @@ -12,12 +12,12 @@ The first defense against CSRF attacks is to ensure that GET requests are side-effect free. POST requests can then be protected by adding this middleware into your list of installed middleware. - .. _Cross Site Request Forgeries: http://www.squarefree.com/securitytips/web-developers.html#CSRF How to use it ============= -Add the middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'`` to + +Add the middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'`` to your list of middleware classes, ``MIDDLEWARE_CLASSES``. It needs to process the response after the SessionMiddleware, so must come before it in the list. It also must process the response before things like compression @@ -25,16 +25,17 @@ happen to the response, so it must come after GZipMiddleware in the list. How it works ============ + CsrfMiddleware does two things: -1. It modifies outgoing requests by adding a hidden form field to all - 'POST' forms, with the name 'csrfmiddlewaretoken' and a value which is - a hash of the session ID plus a secret. If there is no session ID set, - this modification of the response isn't done, so there is very little +1. It modifies outgoing requests by adding a hidden form field to all + 'POST' forms, with the name 'csrfmiddlewaretoken' and a value which is + a hash of the session ID plus a secret. If there is no session ID set, + this modification of the response isn't done, so there is very little performance penalty for those requests that don't have a session. -2. On all incoming POST requests that have the session cookie set, it - checks that the 'csrfmiddlewaretoken' is present and correct. If it +2. On all incoming POST requests that have the session cookie set, it + checks that the 'csrfmiddlewaretoken' is present and correct. If it isn't, the user will get a 403 error. This ensures that only forms that have originated from your web site @@ -43,26 +44,26 @@ can be used to POST data back. It deliberately only targets HTTP POST requests (and the corresponding POST forms). GET requests ought never to have side effects (if you are using HTTP GET and POST correctly), and so a CSRF attack with a GET -request will always be harmless. +request will always be harmless. POST requests that are not accompanied by a session cookie are not protected, but they do not need to be protected, since the 'attacking' web site could make these kind of requests anyway. -The Content-Type is checked before modifying the response, and only +The Content-Type is checked before modifying the response, and only pages that are served as 'text/html' or 'application/xml+xhtml' are modified. Limitations =========== + CsrfMiddleware requires Django's session framework to work. If you have a custom authentication system that manually sets cookies and the like, it won't help you. -If your app creates HTML pages and forms in some unusual way, (e.g. -it sends fragments of HTML in javascript document.write statements) -you might bypass the filter that adds the hidden field to the form, +If your app creates HTML pages and forms in some unusual way, (e.g. +it sends fragments of HTML in javascript document.write statements) +you might bypass the filter that adds the hidden field to the form, in which case form submission will always fail. It may still be possible to use the middleware, provided you can find some way to get the -CSRF token and ensure that is included when your form is submitted. - +CSRF token and ensure that is included when your form is submitted.
\ No newline at end of file diff --git a/docs/db-api.txt b/docs/db-api.txt index 2f0c8b0589..99bb30054b 100644 --- a/docs/db-api.txt +++ b/docs/db-api.txt @@ -143,9 +143,9 @@ or ``UPDATE`` SQL statements. Specifically, when you call ``save()``, Django follows this algorithm: * If the object's primary key attribute is set to a value that evaluates to - ``False`` (such as ``None`` or the empty string), Django executes a - ``SELECT`` query to determine whether a record with the given primary key - already exists. + ``True`` (i.e., a value other than ``None`` or the empty string), Django + executes a ``SELECT`` query to determine whether a record with the given + primary key already exists. * If the record with the given primary key does already exist, Django executes an ``UPDATE`` query. * If the object's primary key attribute is *not* set, or if it's set but a @@ -525,6 +525,21 @@ Examples:: [datetime.datetime(2005, 3, 20), datetime.datetime(2005, 2, 20)] >>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day') [datetime.datetime(2005, 3, 20)] + +``none()`` +~~~~~~~~~~ + +**New in Django development version** + +Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to +an empty list. This can be used in cases where you know that you should +return an empty result set and your caller is expecting a ``QuerySet`` +object (instead of returning an empty list, for example.) + +Examples:: + + >>> Entry.objects.none() + [] ``select_related()`` ~~~~~~~~~~~~~~~~~~~~ @@ -1704,6 +1719,46 @@ For every ``ImageField``, the object will have ``get_FOO_height()`` and ``get_FOO_width()`` methods, where ``FOO`` is the name of the field. This returns the height (or width) of the image, as an integer, in pixels. +Shortcuts +========= + +As you develop views, you will discover a number of common idioms in the +way you use the database API. Django encodes some of these idioms as +shortcuts that can be used to simplify the process of writing views. + +get_object_or_404() +------------------- + +One common idiom to use ``get()`` and raise ``Http404`` if the +object doesn't exist. This idiom is captured by ``get_object_or_404()``. +This function takes a Django model as its first argument and an +arbitrary number of keyword arguments, which it passes to the manager's +``get()`` function. It raises ``Http404`` if the object doesn't +exist. For example:: + + # Get the Entry with a primary key of 3 + e = get_object_or_404(Entry, pk=3) + +When you provide a model to this shortcut function, the default manager +is used to execute the underlying ``get()`` query. If you don't want to +use the default manager, or you want to search a list of related objects, +you can provide ``get_object_or_404()`` with a manager object, instead. +For example:: + + # Get the author of blog instance `e` with a name of 'Fred' + a = get_object_or_404(e.authors, name='Fred') + + # Use a custom manager 'recent_entries' in the search for an + # entry with a primary key of 3 + e = get_object_or_404(Entry.recent_entries, pk=3) + +get_list_or_404() +----------------- + +``get_list_or_404`` behaves the same was as ``get_object_or_404()`` +-- except the it uses using ``filter()`` instead of ``get()``. It raises +``Http404`` if the list is empty. + Falling back to raw SQL ======================= diff --git a/docs/design_philosophies.txt b/docs/design_philosophies.txt index 7fdc7ea01b..72aa8ade95 100644 --- a/docs/design_philosophies.txt +++ b/docs/design_philosophies.txt @@ -186,7 +186,7 @@ code. This is the philosophy behind `template inheritance`_. -.. _template inheritance: http://www.djangoproject.com/documentation/templates/#template-inheritance +.. _template inheritance: ../templates/#template-inheritance Be decoupled from HTML ---------------------- diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 7f9682b443..310e8dff0e 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -53,7 +53,7 @@ Prints the admin-index template snippet for the given appnames. Use admin-index template snippets if you want to customize the look and feel of your admin's index page. See `Tutorial 2`_ for more information. -.. _Tutorial 2: http://www.djangoproject.com/documentation/tutorial2/ +.. _Tutorial 2: ../tutorial2/ createcachetable [tablename] ---------------------------- @@ -61,7 +61,7 @@ createcachetable [tablename] Creates a cache table named ``tablename`` for use with the database cache backend. See the `cache documentation`_ for more information. -.. _cache documentation: http://www.djangoproject.com/documentation/cache/ +.. _cache documentation: ../cache/ dbshell ------- @@ -190,7 +190,7 @@ By default, the development server doesn't serve any static files for your site you want to configure Django to serve static media, read the `serving static files`_ documentation. -.. _serving static files: http://www.djangoproject.com/documentation/static_files/ +.. _serving static files: ../static_files/ Turning off auto-reload ~~~~~~~~~~~~~~~~~~~~~~~ @@ -253,6 +253,8 @@ files are piped directly into the database after all of the models' table-creation statements have been executed. Use this SQL hook to populate tables with any necessary initial records, SQL functions or test data. +Note that the order in which the SQL files are processed is undefined. + sqlreset [appname appname ...] -------------------------------------- @@ -380,7 +382,7 @@ Example usage:: django-admin.py syncdb --verbosity=2 -Verbosity determines the amount of notification and debug information that +Verbosity determines the amount of notification and debug information that will be printed to the console. '0' is no output, '1' is normal output, and `2` is verbose output. diff --git a/docs/email.txt b/docs/email.txt index 37a4f38a5e..1edce88cef 100644 --- a/docs/email.txt +++ b/docs/email.txt @@ -101,9 +101,9 @@ The "From:" header of the e-mail will be the value of the `SERVER_EMAIL setting` This method exists for convenience and readability. -.. _ADMINS setting: http://www.djangoproject.com/documentation/settings/#admins -.. _EMAIL_SUBJECT_PREFIX setting: http://www.djangoproject.com/documentation/settings/#email-subject-prefix -.. _SERVER_EMAIL setting: http://www.djangoproject.com/documentation/settings/#server-email +.. _ADMINS setting: ../settings/#admins +.. _EMAIL_SUBJECT_PREFIX setting: ../settings/#email-subject-prefix +.. _SERVER_EMAIL setting: ../settings/#server-email mail_managers() function ======================== @@ -114,7 +114,7 @@ Here's the definition:: mail_managers(subject, message, fail_silently=False) -.. _MANAGERS setting: http://www.djangoproject.com/documentation/settings/#managers +.. _MANAGERS setting: ../settings/#managers Examples ======== diff --git a/docs/faq.txt b/docs/faq.txt index eaccc6be43..33e8ef01b4 100644 --- a/docs/faq.txt +++ b/docs/faq.txt @@ -63,7 +63,7 @@ at any level -- database servers, caching servers or Web/application servers. The framework cleanly separates components such as its database layer and application layer. And it ships with a simple-yet-powerful `cache framework`_. -.. _`cache framework`: http://www.djangoproject.com/documentation/cache/ +.. _`cache framework`: ../cache/ Who's behind this? ------------------ @@ -191,7 +191,7 @@ Like we said: We're picky. We've documented our philosophies on the `design philosophies page`_. -.. _design philosophies page: http://www.djangoproject.com/documentation/design_philosophies/ +.. _design philosophies page: ../design_philosophies/ Do you have any of those nifty "screencast" things? --------------------------------------------------- @@ -277,9 +277,9 @@ How do I get started? run into trouble. .. _`Download the code`: http://www.djangoproject.com/download/ -.. _`installation guide`: http://www.djangoproject.com/documentation/install/ -.. _tutorial: http://www.djangoproject.com/documentation/tutorial1/ -.. _documentation: http://www.djangoproject.com/documentation/ +.. _`installation guide`: ../install/ +.. _tutorial: ../tutorial1/ +.. _documentation: ../ .. _ask questions: http://www.djangoproject.com/community/ How do I fix the "install a later version of setuptools" error? @@ -337,7 +337,7 @@ If you just want to play around and develop things on your local computer, use the development Web server that comes with Django. Things should Just Work. .. _WSGI: http://www.python.org/peps/pep-0333.html -.. _How to use Django with FastCGI: http://www.djangoproject.com/documentation/fastcgi/ +.. _How to use Django with FastCGI: ../fastcgi/ .. _server arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements How do I install mod_python on Windows? @@ -464,7 +464,7 @@ Can I use Django with a pre-existing database? Yes. See `Integrating with a legacy database`_. -.. _`Integrating with a legacy database`: http://www.djangoproject.com/documentation/legacy_databases/ +.. _`Integrating with a legacy database`: ../legacy_databases/ If I make changes to a model, how do I update the database? ----------------------------------------------------------- @@ -511,7 +511,7 @@ type, create an initial data file and put something like this in it:: As explained in the `SQL initial data file`_ documentation, this SQL file can contain arbitrary SQL, so you can make any sorts of changes you need to make. -.. _SQL initial data file: http://www.djangoproject.com/documentation/model_api/#providing-initial-sql-data +.. _SQL initial data file: ../model_api/#providing-initial-sql-data Why is Django leaking memory? ----------------------------- @@ -592,7 +592,7 @@ My admin-site CSS and images showed up fine using the development server, but th See `serving the admin files`_ in the "How to use Django with mod_python" documentation. -.. _serving the admin files: http://www.djangoproject.com/documentation/modpython/#serving-the-admin-files +.. _serving the admin files: ../modpython/#serving-the-admin-files My "list_filter" contains a ManyToManyField, but the filter doesn't display. ---------------------------------------------------------------------------- @@ -630,7 +630,7 @@ site is built using semantic HTML and plenty of CSS hooks, so any changes you'd like to make should be possible by editing the stylesheet. We've got a `guide to the CSS used in the admin`_ to get you started. -.. _`guide to the CSS used in the admin`: http://www.djangoproject.com/documentation/admin_css/ +.. _`guide to the CSS used in the admin`: ../admin_css/ How do I create users without having to edit password hashes? ------------------------------------------------------------- @@ -640,7 +640,7 @@ development version, where this problem was fixed on Aug. 4, 2006. You can also use the Python API. See `creating users`_ for full info. -.. _creating users: http://www.djangoproject.com/documentation/authentication/#creating-users +.. _creating users: ../authentication/#creating-users Contributing code ================= @@ -651,7 +651,7 @@ How can I get started contributing code to Django? Thanks for asking! We've written an entire document devoted to this question. It's titled `Contributing to Django`_. -.. _Contributing to Django: http://www.djangoproject.com/documentation/contributing/ +.. _Contributing to Django: ../contributing/ I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch? -------------------------------------------------------------------------------------------- diff --git a/docs/fastcgi.txt b/docs/fastcgi.txt index e2f4e933b4..b61df49190 100644 --- a/docs/fastcgi.txt +++ b/docs/fastcgi.txt @@ -17,7 +17,7 @@ served with no startup time. Unlike mod_python (or `mod_perl`_), a FastCGI process doesn't run inside the Web server process, but in a separate, persistent process. -.. _current preferred setup: http://www.djangoproject.com/documentation/modpython/ +.. _current preferred setup: ../modpython/ .. _Apache: http://httpd.apache.org/ .. _mod_python: http://www.modpython.org/ .. _mod_perl: http://perl.apache.org/ diff --git a/docs/flatpages.txt b/docs/flatpages.txt index 06979f7a9a..cb910e812d 100644 --- a/docs/flatpages.txt +++ b/docs/flatpages.txt @@ -29,8 +29,8 @@ To install the flatpages app, follow these steps: to your MIDDLEWARE_CLASSES_ setting. 3. Run the command ``manage.py syncdb``. -.. _INSTALLED_APPS: http://www.djangoproject.com/documentation/settings/#installed-apps -.. _MIDDLEWARE_CLASSES: http://www.djangoproject.com/documentation/settings/#middleware-classes +.. _INSTALLED_APPS: ../settings/#installed-apps +.. _MIDDLEWARE_CLASSES: ../settings/#middleware-classes How it works ============ @@ -63,9 +63,9 @@ resort. For more on middleware, read the `middleware docs`_. -.. _SITE_ID: http://www.djangoproject.com/documentation/settings/#site-id -.. _RequestContext: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext -.. _middleware docs: http://www.djangoproject.com/documentation/middleware/ +.. _SITE_ID: ../settings/#site-id +.. _RequestContext: ../templates_python/#subclassing-context-djangocontext +.. _middleware docs: ../middleware/ How to add, change and delete flatpages ======================================= @@ -84,9 +84,9 @@ Flatpages are represented by a standard `Django model`_, which lives in `django/contrib/flatpages/models.py`_. You can access flatpage objects via the `Django database API`_. -.. _Django model: http://www.djangoproject.com/documentation/model_api/ +.. _Django model: ../model_api/ .. _django/contrib/flatpages/models.py: http://code.djangoproject.com/browser/django/trunk/django/contrib/flatpages/models.py -.. _Django database API: http://www.djangoproject.com/documentation/db_api/ +.. _Django database API: ../db_api/ Flatpage templates ================== diff --git a/docs/forms.txt b/docs/forms.txt index ff192a4717..3fa11fea64 100644 --- a/docs/forms.txt +++ b/docs/forms.txt @@ -2,15 +2,27 @@ Forms, fields, and manipulators =============================== +Forwards-compatibility note +=========================== + +The legacy forms/manipulators system described in this document is going to be +replaced in the next Django release. If you're starting from scratch, we +strongly encourage you not to waste your time learning this. Instead, learn and +use the django.newforms system, which we have begun to document in the +`newforms documentation`_. + +If you have legacy form/manipulator code, read the "Migration plan" section in +that document to understand how we're making the switch. + +.. _newforms documentation: ../newforms/ + +Introduction +============ + Once you've got a chance to play with Django's admin interface, you'll probably wonder if the fantastic form validation framework it uses is available to user code. It is, and this document explains how the framework works. - .. admonition:: A note to the lazy - - If all you want to do is present forms for a user to create and/or - update a given object, you may be able to use `generic views`_. - We'll take a top-down approach to examining Django's form validation framework, because much of the time you won't need to use the lower-level APIs. Throughout this document, we'll be working with the following model, a "place" object:: @@ -41,17 +53,17 @@ this document, we'll be working with the following model, a "place" object:: Defining the above class is enough to create an admin interface to a ``Place``, but what if you want to allow public users to submit places? -Manipulators -============ +Automatic Manipulators +====================== The highest-level interface for object creation and modification is the -**Manipulator** framework. A manipulator is a utility class tied to a given -model that "knows" how to create or modify instances of that model and how to -validate data for the object. Manipulators come in two flavors: -``AddManipulators`` and ``ChangeManipulators``. Functionally they are quite -similar, but the former knows how to create new instances of the model, while -the latter modifies existing instances. Both types of classes are automatically -created when you define a new class:: +**automatic Manipulator** framework. An automatic manipulator is a utility +class tied to a given model that "knows" how to create or modify instances of +that model and how to validate data for the object. Automatic Manipulators come +in two flavors: ``AddManipulators`` and ``ChangeManipulators``. Functionally +they are quite similar, but the former knows how to create new instances of the +model, while the latter modifies existing instances. Both types of classes are +automatically created when you define a new class:: >>> from mysite.myapp.models import Place >>> Place.AddManipulator @@ -653,6 +665,6 @@ fails. If no message is passed in, a default message is used. the executable specified in the ``JING_PATH`` setting (see the settings_ document for more details). -.. _`generic views`: http://www.djangoproject.com/documentation/generic_views/ -.. _`models API`: http://www.djangoproject.com/documentation/model_api/ -.. _settings: http://www.djangoproject.com/documentation/settings/ +.. _`generic views`: ../generic_views/ +.. _`models API`: ../model_api/ +.. _settings: ../settings/ diff --git a/docs/generic_views.txt b/docs/generic_views.txt index 1736770a20..23f40acb24 100644 --- a/docs/generic_views.txt +++ b/docs/generic_views.txt @@ -71,7 +71,7 @@ are first evaluated, so if you want to pass in a QuerySet via ``extra_context`` that is always fresh you need to wrap it in a function or lambda that returns the QuerySet. -.. _database API docs: http://www.djangoproject.com/documentation/db_api/ +.. _database API docs: ../db_api/ "Simple" generic views ====================== @@ -99,7 +99,7 @@ which is a dictionary of the parameters captured in the URL. dictionary is callable, the generic view will call it just before rendering the template. (**This is new in the Django development version.**) - + **Example:** Given the following URL patterns:: @@ -205,11 +205,11 @@ If ``template_name`` isn't specified, this view will use the template ``<app_label>/<model_name>_archive.html`` by default, where: * ``<model_name>`` is your model's name in all lowercase. For a model - ``StaffMember``, that'd be ``staffmember``. + ``StaffMember``, that'd be ``staffmember``. * ``<app_label>`` is the right-most part of the full Python path to - your model's app. For example, if your model lives in - ``apps/blog/models.py``, that'd be ``blog``. + your model's app. For example, if your model lives in + ``apps/blog/models.py``, that'd be ``blog``. **Template context:** @@ -223,7 +223,7 @@ In addition to ``extra_context``, the template's context will be: by ``date_field``. For example, if ``num_latest`` is ``10``, then ``latest`` will be a list of the latest 10 objects in ``queryset``. -.. _RequestContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext +.. _RequestContext docs: ../templates_python/#subclassing-context-djangocontext ``django.views.generic.date_based.archive_year`` ------------------------------------------------ @@ -266,9 +266,9 @@ to ``True``. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. The - view will append ``'_list'`` to the value of this parameter in - determining the variable's name. + to use in the template context. By default, this is ``'object'``. The + view will append ``'_list'`` to the value of this parameter in + determining the variable's name. * ``make_object_list``: A boolean specifying whether to retrieve the full list of objects for this year and pass those to the template. If ``True``, @@ -360,9 +360,9 @@ date in the *future* are not displayed unless you set ``allow_future`` to the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. The - view will append ``'_list'`` to the value of this parameter in - determining the variable's name. + to use in the template context. By default, this is ``'object'``. The + view will append ``'_list'`` to the value of this parameter in + determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -441,9 +441,9 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. The - view will append ``'_list'`` to the value of this parameter in - determining the variable's name. + to use in the template context. By default, this is ``'object'``. The + view will append ``'_list'`` to the value of this parameter in + determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -526,9 +526,9 @@ you set ``allow_future`` to ``True``. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. The - view will append ``'_list'`` to the value of this parameter in - determining the variable's name. + to use in the template context. By default, this is ``'object'``. The + view will append ``'_list'`` to the value of this parameter in + determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -638,7 +638,7 @@ future, the view will throw a 404 error by default, unless you set the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. + to use in the template context. By default, this is ``'object'``. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -710,9 +710,9 @@ A page representing a list of objects. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. The - view will append ``'_list'`` to the value of this parameter in - determining the variable's name. + to use in the template context. By default, this is ``'object'``. The + view will append ``'_list'`` to the value of this parameter in + determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -824,7 +824,7 @@ A page representing an individual object. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. + to use in the template context. By default, this is ``'object'``. * ``mimetype``: The MIME type to use for the resulting document. Defaults to the value of the ``DEFAULT_CONTENT_TYPE`` setting. @@ -902,7 +902,7 @@ If ``template_name`` isn't specified, this view will use the template In addition to ``extra_context``, the template's context will be: - * ``form``: A ``django.forms.FormWrapper`` instance representing the form + * ``form``: A ``django.oldforms.FormWrapper`` instance representing the form for editing the object. This lets you refer to form fields easily in the template system. @@ -916,8 +916,8 @@ In addition to ``extra_context``, the template's context will be: See the `manipulator and formfield documentation`_ for more information about using ``FormWrapper`` objects in templates. -.. _authentication system: http://www.djangoproject.com/documentation/authentication/ -.. _manipulator and formfield documentation: http://www.djangoproject.com/documentation/forms/ +.. _authentication system: ../authentication/ +.. _manipulator and formfield documentation: ../forms/ ``django.views.generic.create_update.update_object`` ---------------------------------------------------- @@ -973,7 +973,7 @@ object. This uses the automatic manipulators that come with Django models. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. + to use in the template context. By default, this is ``'object'``. **Template name:** @@ -984,7 +984,7 @@ If ``template_name`` isn't specified, this view will use the template In addition to ``extra_context``, the template's context will be: - * ``form``: A ``django.forms.FormWrapper`` instance representing the form + * ``form``: A ``django.oldforms.FormWrapper`` instance representing the form for editing the object. This lets you refer to form fields easily in the template system. @@ -1054,7 +1054,7 @@ contain a form that POSTs to the same URL. the view's template. See the `RequestContext docs`_. * ``template_object_name``: Designates the name of the template variable - to use in the template context. By default, this is ``'object'``. + to use in the template context. By default, this is ``'object'``. **Template name:** diff --git a/docs/i18n.txt b/docs/i18n.txt index 4d0d92b082..d7f5db6861 100644 --- a/docs/i18n.txt +++ b/docs/i18n.txt @@ -53,7 +53,7 @@ internationalization machinery. See the `documentation for USE_I18N`_. You'll probably also want to remove ``'django.core.context_processors.i18n'`` from your ``TEMPLATE_CONTEXT_PROCESSORS`` setting. -.. _documentation for USE_I18N: http://www.djangoproject.com/documentation/settings/#use-i18n +.. _documentation for USE_I18N: ../settings/#use-i18n How to specify translation strings ================================== @@ -175,7 +175,7 @@ class, though:: verbose_name = _('my thing') verbose_name_plural = _('mythings') -.. _Django models: http://www.djangoproject.com/documentation/model_api/ +.. _Django models: ../model_api/ Pluralization ~~~~~~~~~~~~~ @@ -274,7 +274,7 @@ translation string. Example:: In this case, both the tag and the filter will see the already-translated string, so they don't need to be aware of translations. -.. _Django templates: http://www.djangoproject.com/documentation/templates_python/ +.. _Django templates: ../templates_python/ How to create language files ============================ @@ -394,7 +394,7 @@ That's it. Your translations are ready for use. please let us know! See `Submitting and maintaining translations`_ for the steps to take. - .. _Submitting and maintaining translations: http://www.djangoproject.com/documentation/contributing/ + .. _Submitting and maintaining translations: ../contributing/ How Django discovers language preference ======================================== @@ -472,7 +472,7 @@ Notes: selection to German and English (and any sublanguage, like de-ch or en-us). - .. _LANGUAGES setting: http://www.djangoproject.com/documentation/settings/#languages + .. _LANGUAGES setting: ../settings/#languages * If you define a custom ``LANGUAGES`` setting, as explained in the previous bullet, it's OK to mark the languages as translation strings @@ -530,10 +530,10 @@ Note that, with static (middleware-less) translation, the language is in ``settings.LANGUAGE_CODE``, while with dynamic (middleware) translation, it's in ``request.LANGUAGE_CODE``. -.. _settings file: http://www.djangoproject.com/documentation/settings/ -.. _middleware documentation: http://www.djangoproject.com/documentation/middleware/ -.. _session: http://www.djangoproject.com/documentation/sessions/ -.. _request object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects +.. _settings file: ../settings/ +.. _middleware documentation: ../middleware/ +.. _session: ../sessions/ +.. _request object: ../request_response/#httprequest-objects The ``set_language`` redirect view ================================== @@ -599,7 +599,7 @@ message file. The choice is yours. of the settings file to determine this, and a settings file doesn't exist if you're manually configuring your settings.) -.. _settings documentation: http://www.djangoproject.com/documentation/settings/#using-settings-without-the-django-settings-module-environment-variable +.. _settings documentation: ../settings/#using-settings-without-the-django-settings-module-environment-variable All message file repositories are structured the same way. They are: diff --git a/docs/install.txt b/docs/install.txt index ff8e1a8318..89a1415f5a 100644 --- a/docs/install.txt +++ b/docs/install.txt @@ -38,7 +38,7 @@ each platform. .. _Apache: http://httpd.apache.org/ .. _mod_python: http://www.modpython.org/ .. _WSGI: http://www.python.org/peps/pep-0333.html -.. _How to use Django with mod_python: http://www.djangoproject.com/documentation/modpython/ +.. _How to use Django with mod_python: ../modpython/ .. _server-arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements Get your database running @@ -113,14 +113,14 @@ latest bug fixes and improvements, follow these instructions: svn co http://code.djangoproject.com/svn/django/trunk/django c:\Python24\lib\site-packages\django -4. Copy the file ``django_src/django/bin/django-admin.py`` to somewhere on your +3. Copy the file ``django_src/django/bin/django-admin.py`` to somewhere on your system path, such as ``/usr/local/bin`` (Unix) or ``C:\Python24\Scripts`` (Windows). This step simply lets you type ``django-admin.py`` from within any directory, rather than having to qualify the command with the full path to the file. You *don't* have to run ``python setup.py install``, because that command -takes care of steps 3 and 4 for you. +takes care of steps 2 and 3 for you. When you want to update your copy of the Django source code, just run the command ``svn update`` from within the ``django`` directory. When you do this, diff --git a/docs/legacy_databases.txt b/docs/legacy_databases.txt index 66cb1a2ef4..8230c11f61 100644 --- a/docs/legacy_databases.txt +++ b/docs/legacy_databases.txt @@ -9,7 +9,7 @@ utilities to automate as much of this process as possible. This document assumes you know the Django basics, as covered in the `official tutorial`_. -.. _official tutorial: http://www.djangoproject.com/documentation/tutorial1/ +.. _official tutorial: ../tutorial1/ Give Django your database parameters ==================================== @@ -22,18 +22,16 @@ what the name of the database is. Do that by editing these settings in your * `DATABASE_ENGINE`_ * `DATABASE_USER`_ * `DATABASE_PASSWORD`_ - * `DATABASE_NAME`_ * `DATABASE_HOST`_ * `DATABASE_PORT`_ -.. _settings file: http://www.djangoproject.com/documentation/settings/ -.. _DATABASE_NAME: http://www.djangoproject.com/documentation/settings/#database-name -.. _DATABASE_ENGINE: http://www.djangoproject.com/documentation/settings/#database-engine -.. _DATABASE_USER: http://www.djangoproject.com/documentation/settings/#database-user -.. _DATABASE_PASSWORD: http://www.djangoproject.com/documentation/settings/#database-password -.. _DATABASE_NAME: http://www.djangoproject.com/documentation/settings/#database-name -.. _DATABASE_HOST: http://www.djangoproject.com/documentation/settings/#database-host -.. _DATABASE_PORT: http://www.djangoproject.com/documentation/settings/#database-port +.. _settings file: ../settings/ +.. _DATABASE_NAME: ../settings/#database-name +.. _DATABASE_ENGINE: ../settings/#database-engine +.. _DATABASE_USER: ../settings/#database-user +.. _DATABASE_PASSWORD: ../settings/#database-password +.. _DATABASE_HOST: ../settings/#database-host +.. _DATABASE_PORT: ../settings/#database-port Auto-generate the models ======================== @@ -54,7 +52,7 @@ Once you've cleaned up your models, name the file ``models.py`` and put it in the Python package that holds your app. Then add the app to your ``INSTALLED_APPS`` setting. -.. _django-admin.py documentation: http://www.djangoproject.com/documentation/django_admin/ +.. _django-admin.py documentation: ../django_admin/ Install the core Django tables ============================== diff --git a/docs/middleware.txt b/docs/middleware.txt index efc4d89569..7635442a5c 100644 --- a/docs/middleware.txt +++ b/docs/middleware.txt @@ -47,7 +47,7 @@ Enables site-wide cache. If this is enabled, each Django-powered page will be cached for as long as the ``CACHE_MIDDLEWARE_SECONDS`` setting defines. See the `cache documentation`_. -.. _`cache documentation`: http://www.djangoproject.com/documentation/cache/#the-per-site-cache +.. _`cache documentation`: ../cache/#the-per-site-cache django.middleware.common.CommonMiddleware ----------------------------------------- @@ -106,9 +106,10 @@ django.middleware.http.SetRemoteAddrFromForwardedFor **New in Django development version** -Sets ``request['REMOTE_ADDR']`` based on ``request.['HTTP_X_FORWARDED_FOR']``, -if the latter is set. This is useful if you're sitting behind a reverse proxy -that causes each request's ``REMOTE_ADDR`` to be set to ``127.0.0.1``. +Sets ``request.META['REMOTE_ADDR']`` based on +``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful +if you're sitting behind a reverse proxy that causes each request's +``REMOTE_ADDR`` to be set to ``127.0.0.1``. **Important note:** This does NOT validate ``HTTP_X_FORWARDED_FOR``. If you're not behind a reverse proxy that sets ``HTTP_X_FORWARDED_FOR`` automatically, do @@ -122,7 +123,7 @@ django.contrib.sessions.middleware.SessionMiddleware Enables session support. See the `session documentation`_. -.. _`session documentation`: http://www.djangoproject.com/documentation/sessions/ +.. _`session documentation`: ../sessions/ django.contrib.auth.middleware.AuthenticationMiddleware ------------------------------------------------------- @@ -130,7 +131,7 @@ django.contrib.auth.middleware.AuthenticationMiddleware Adds the ``user`` attribute, representing the currently-logged-in user, to every incoming ``HttpRequest`` object. See `Authentication in Web requests`_. -.. _Authentication in Web requests: http://www.djangoproject.com/documentation/authentication/#authentication-in-web-requests +.. _Authentication in Web requests: ../authentication/#authentication-in-web-requests django.middleware.transaction.TransactionMiddleware --------------------------------------------------- @@ -146,7 +147,7 @@ the same transaction control as the view functions. See the `transaction management documentation`_. -.. _`transaction management documentation`: http://www.djangoproject.com/documentation/transactions/ +.. _`transaction management documentation`: ../transactions/ Writing your own middleware =========================== diff --git a/docs/model-api.txt b/docs/model-api.txt index 1aa8c811f4..8abd88f7ec 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -94,7 +94,7 @@ Django places only two restrictions on model field names: the way Django's query lookup syntax works. For example:: class Example(models.Model): - foo__bar = models.IntegerField() 'foo__bar' has two underscores! + foo__bar = models.IntegerField() # 'foo__bar' has two underscores! These limitations can be worked around, though, because your field name doesn't necessarily have to match your database column name. See `db_column`_ below. @@ -874,6 +874,10 @@ the relationship should work. All are optional: force Django to add the descriptor for the reverse relationship, allowing ``ManyToMany`` relationships to be non-symmetrical. + + ``db_table`` The name of the table to create for storing the many-to-many + data. If this is not provided, Django will assume a default + name based upon the names of the two tables being joined. ======================= ============================================================ @@ -1268,6 +1272,24 @@ A few special cases to note about ``list_display``: return '<span style="color: #%s;">%s %s</span>' % (self.color_code, self.first_name, self.last_name) colored_name.allow_tags = True + * If the string given is a method of the model that returns True or False + Django will display a pretty "on" or "off" icon if you give the method a + ``boolean`` attribute whose value is ``True``. + + Here's a full example model:: + + class Person(models.Model): + first_name = models.CharField(maxlength=50) + birthday = models.DateField() + + class Admin: + list_display = ('name', 'born_in_fifties') + + def born_in_fifties(self): + return self.birthday.strftime('%Y')[:3] == 5 + born_in_fifties.boolean = True + + * The ``__str__()`` method is just as valid in ``list_display`` as any other model method, so it's perfectly OK to do this:: @@ -1390,7 +1412,10 @@ This should be set to a list of field names that will be searched whenever somebody submits a search query in that text box. These fields should be some kind of text field, such as ``CharField`` or -``TextField``. +``TextField``. You can also perform a related lookup on a ``ForeignKey`` with +the lookup API "follow" notation:: + + search_fields = ['foreign_key__related_fieldname'] When somebody does a search in the admin search box, Django splits the search query into words and returns all objects that contain each of the words, case diff --git a/docs/modpython.txt b/docs/modpython.txt index 5177abf728..2c999753c7 100644 --- a/docs/modpython.txt +++ b/docs/modpython.txt @@ -20,7 +20,7 @@ You may also be interested in `How to use Django with FastCGI`_. .. _mod_perl: http://perl.apache.org/ .. _prefork MPM: http://httpd.apache.org/docs/2.2/mod/prefork.html .. _worker MPM: http://httpd.apache.org/docs/2.2/mod/worker.html -.. _How to use Django with FastCGI: http://www.djangoproject.com/documentation/fastcgi/ +.. _How to use Django with FastCGI: ../fastcgi/ Basic configuration =================== diff --git a/docs/newforms.txt b/docs/newforms.txt index 9bfbc75ee7..063f686ed5 100644 --- a/docs/newforms.txt +++ b/docs/newforms.txt @@ -2,9 +2,9 @@ The newforms library ==================== -``django.newforms`` is a new replacement for ``django.forms``, the old Django -form/manipulator/validation framework. This document explains how to use this -new form library. +``django.newforms`` is Django's fantastic new form-handling library. It's a +replacement for ``django.forms``, the old form/manipulator/validation +framework. This document explains how to use this new library. Migration plan ============== @@ -13,18 +13,23 @@ Migration plan -- i.e., it's not available in the Django 0.95 release. For the next Django release, our plan is to do the following: - * Move the current ``django.forms`` to ``django.oldforms``. This will allow - for an eased migration of form code. You'll just have to change your - import statements:: + * As of revision [4208], we've copied the current ``django.forms`` to + ``django.oldforms``. This allows you to upgrade your code *now* rather + than waiting for the backwards-incompatible change and rushing to fix + your code after the fact. Just change your import statements like this:: from django import forms # old from django import oldforms as forms # new - * Move the current ``django.newforms`` to ``django.forms``. + * At an undecided future date, we will move the current ``django.newforms`` + to ``django.forms``. This will be a backwards-incompatible change, and + anybody who is still using the old version of ``django.forms`` at that + time will need to change their import statements, as described in the + previous bullet. * We will remove ``django.oldforms`` in the release *after* the next Django release -- the release that comes after the release in which we're - creating ``django.oldforms``. + creating the new ``django.forms``. With this in mind, we recommend you use the following import statement when using ``django.newforms``:: @@ -46,9 +51,14 @@ too messy. The choice is yours. Overview ======== -As the ``django.forms`` system before it, ``django.newforms`` is intended to -handle HTML form display, validation and redisplay. It's what you use if you -want to perform server-side validation for an HTML form. +As with the ``django.forms`` ("manipulators") system before it, ``django.newforms`` +is intended to handle HTML form display, validation and redisplay. It's what +you use if you want to perform server-side validation for an HTML form. + +For example, if your Web site has a contact form that visitors can use to +send you e-mail, you'd use this library to implement the display of the HTML +form fields, along with the form validation. Any time you need to use an HTML +``<form>``, you can use this library. The library deals with these concepts: @@ -62,13 +72,751 @@ The library deals with these concepts: * **Form** -- A collection of fields that knows how to validate itself and display itself as HTML. +The library is decoupled from the other Django components, such as the database +layer, views and templates. It relies only on Django settings, a couple of +``django.utils`` helper functions and Django's internationalization hooks (but +you're not required to be using internationalization features to use this +library). +Form objects +============ -Using forms with templates -========================== +The primary way of using the ``newforms`` library is to create a form object. +Do this by subclassing ``django.newforms.Form`` and specifying the form's +fields, in a declarative style that you'll be familiar with if you've used +Django database models. In this section, we'll iteratively develop a form +object that you might use to implement "contact me" functionality on your +personal Web site. -Using forms in views -==================== +Start with this basic ``Form`` subclass, which we'll call ``ContactForm``:: + + from django import newforms as forms + + class ContactForm(forms.Form): + subject = forms.CharField(max_length=100) + message = forms.CharField() + sender = forms.EmailField() + cc_myself = forms.BooleanField() + +A form is composed of ``Field`` objects. In this case, our form has four +fields: ``subject``, ``message``, ``sender`` and ``cc_myself``. We'll explain +the different types of fields -- e.g., ``CharField`` and ``EmailField`` -- +shortly. + +Creating ``Form`` instances +--------------------------- + +A ``Form`` instance is either **bound** or **unbound** to a set of data. + + * If it's **bound** to a set of data, it's capable of validating that data + and rendering the form as HTML with the data displayed in the HTML. + + * If it's **unbound**, it cannot do validation (because there's no data to + validate!), but it can still render the blank form as HTML. + +To create an unbound ``Form`` instance, simply instantiate the class:: + + >>> f = ContactForm() + +To bind data to a form, pass the data as a dictionary as the first parameter to +your ``Form`` class constructor:: + + >>> data = {'subject': 'hello', + ... 'message': 'Hi there', + ... 'sender': 'foo@example.com', + ... 'cc_myself': True} + >>> f = ContactForm(data) + +In this dictionary, the keys are the field names, which correspond to the +attributes in your ``Form`` class. The values are the data you're trying +to validate. These will usually be strings, but there's no requirement that +they be strings; the type of data you pass depends on the ``Field``, as we'll +see in a moment. + +If you need to distinguish between bound and unbound form instances at runtime, +check the value of the form's ``is_bound`` attribute:: + + >>> f = ContactForm() + >>> f.is_bound + False + >>> f = ContactForm({'subject': 'hello'}) + >>> f.is_bound + True + +Note that passing an empty dictionary creates a *bound* form with empty data:: + + >>> f = ContactForm({}) + >>> f.is_bound + True + +If you have a bound ``Form`` instance and want to change the data somehow, or +if you want to bind an unbound ``Form`` instance to some data, create another +``Form`` instance. There is no way to change data in a ``Form`` instance. Once +a ``Form`` instance has been created, you should consider its data immutable, +whether it has data or not. + +Using forms to validate data +---------------------------- + +The primary task of a ``Form`` object is to validate data. With a bound +``Form`` instance, call the ``is_valid()`` method to run validation and return +a boolean designating whether the data was valid:: + + >>> data = {'subject': 'hello', + ... 'message': 'Hi there', + ... 'sender': 'foo@example.com', + ... 'cc_myself': True} + >>> f = ContactForm(data) + >>> f.is_valid() + True + +Let's try with some invalid data. In this case, ``subject`` is blank (an error, +because all fields are required by default) and ``sender`` is not a valid +e-mail address:: + + >>> data = {'subject': '', + ... 'message': 'Hi there', + ... 'sender': 'invalid e-mail address', + ... 'cc_myself': True} + >>> f = ContactForm(data) + >>> f.is_valid() + False + +Access the ``Form`` attribute ``errors`` to get a dictionary of error messages:: + + >>> f.errors + {'sender': [u'Enter a valid e-mail address.'], 'subject': [u'This field is required.']} + +In this dictionary, the keys are the field names, and the values are lists of +Unicode strings representing the error messages. The error messages are stored +in lists because a field can have multiple error messages. + +You can access ``errors`` without having to call ``is_valid()`` first. The +form's data will be validated the first time either you call ``is_valid()`` or +access ``errors``. + +Behavior of unbound forms +~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's meaningless to validate a form with no data, but, for the record, here's +what happens with unbound forms:: + + >>> f = ContactForm() + >>> f.is_valid() + False + >>> f.errors + {} + +Accessing "clean" data +---------------------- + +Each ``Field`` in a ``Form`` class is responsible not only for validating data, +but also for "cleaning" it -- normalizing it to a consistent format. This is a +nice feature, because it allows data for a particular field to be input in +a variety of ways, always resulting in consistent output. + +For example, ``DateField`` normalizes input into a Python ``datetime.date`` +object. Regardless of whether you pass it a string in the format +``'1994-07-15'``, a ``datetime.date`` object or a number of other formats, +``DateField`` will always normalize it to a ``datetime.date`` object as long as +it's valid. + +Once you've created a ``Form`` instance with a set of data and validated it, +you can access the clean data via the ``clean_data`` attribute of the ``Form`` +object:: + + >>> data = {'subject': 'hello', + ... 'message': 'Hi there', + ... 'sender': 'foo@example.com', + ... 'cc_myself': True} + >>> f = ContactForm(data) + >>> f.is_valid() + True + >>> f.clean_data + {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'} + +Note that any text-based field -- such as ``CharField`` or ``EmailField`` -- +always cleans the input into a Unicode string. We'll cover the encoding +implications later in this document. + +If your data does *not* validate, your ``Form`` instance will not have a +``clean_data`` attribute:: + + >>> data = {'subject': '', + ... 'message': 'Hi there', + ... 'sender': 'invalid e-mail address', + ... 'cc_myself': True} + >>> f = ContactForm(data) + >>> f.is_valid() + False + >>> f.clean_data + Traceback (most recent call last): + ... + AttributeError: 'ContactForm' object has no attribute 'clean_data' + +``clean_data`` will always *only* contain a key for fields defined in the +``Form``, even if you pass extra data when you define the ``Form``. In this +example, we pass a bunch of extra fields to the ``ContactForm`` constructor, +but ``clean_data`` contains only the form's fields:: + + >>> data = {'subject': 'hello', + ... 'message': 'Hi there', + ... 'sender': 'foo@example.com', + ... 'cc_myself': True, + ... 'extra_field_1': 'foo', + ... 'extra_field_2': 'bar', + ... 'extra_field_3': 'baz'} + >>> f = ContactForm(data) + >>> f.is_valid() + True + >>> f.clean_data # Doesn't contain extra_field_1, etc. + {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'} + +Behavior of unbound forms +~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's meaningless to request "clean" data in a form with no data, but, for the +record, here's what happens with unbound forms:: + + >>> f = ContactForm() + >>> f.clean_data + Traceback (most recent call last): + ... + AttributeError: 'ContactForm' object has no attribute 'clean_data' + +Outputting forms as HTML +------------------------ + +The second task of a ``Form`` object is to render itself as HTML. To do so, +simply ``print`` it:: + + >>> f = ContactForm() + >>> print f + <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr> + <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr> + <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr> + <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr> + +If the form is bound to data, the HTML output will include that data +appropriately. For example, if a field is represented by an +``<input type="text">``, the data will be in the ``value`` attribute. If a +field is represented by an ``<input type="checkbox">``, then that HTML will +include ``checked="checked"`` if appropriate:: + + >>> data = {'subject': 'hello', + ... 'message': 'Hi there', + ... 'sender': 'foo@example.com', + ... 'cc_myself': True} + >>> f = ContactForm(data) + >>> print f + <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" value="hello" /></td></tr> + <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" value="Hi there" /></td></tr> + <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" value="foo@example.com" /></td></tr> + <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" checked="checked" /></td></tr> + +This default output is a two-column HTML table, with a ``<tr>`` for each field. +Notice the following: + + * For flexibility, the output does *not* include the ``<table>`` and + ``</table>`` tags, nor does it include the ``<form>`` and ``</form>`` + tags or an ``<input type="submit">`` tag. It's your job to do that. + + * Each field type has a default HTML representation. ``CharField`` and + ``EmailField`` are represented by an ``<input type="text">``. + ``BooleanField`` is represented by an ``<input type="checkbox">``. Note + these are merely sensible defaults; you can specify which HTML to use for + a given field by using widgets, which we'll explain shortly. + + * The HTML ``name`` for each tag is taken directly from its attribute name + in the ``ContactForm`` class. + + * The text label for each field -- e.g. ``'Subject:'``, ``'Message:'`` and + ``'Cc myself:'`` is generated from the field name by converting all + underscores to spaces and upper-casing the first letter. Again, note + these are merely sensible defaults; you can also specify labels manually. + + * Each text label is surrounded in an HTML ``<label>`` tag, which points + to the appropriate form field via its ``id``. Its ``id``, in turn, is + generated by prepending ``'id_'`` to the field name. The ``id`` + attributes and ``<label>`` tags are included in the output by default, to + follow best practices, but you can change that behavior. + +Although ``<table>`` output is the default output style when you ``print`` a +form, other output styles are available. Each style is available as a method on +a form object, and each rendering method returns a Unicode object. + +``as_p()`` +~~~~~~~~~~ + +``Form.as_p()`` renders the form as a series of ``<p>`` tags, with each ``<p>`` +containing one field:: + + >>> f = ContactForm() + >>> f.as_p() + u'<p><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></p>\n<p><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></p>\n<p><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></p>\n<p><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></p>' + >>> print f.as_p() + <p><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></p> + <p><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></p> + <p><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></p> + <p><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></p> + +``as_ul()`` +~~~~~~~~~~~ + +``Form.as_ul()`` renders the form as a series of ``<li>`` tags, with each +``<li>`` containing one field. It does *not* include the ``<ul>`` or ``</ul>``, +so that you can specify any HTML attributes on the ``<ul>`` for flexibility:: + + >>> f = ContactForm() + >>> f.as_ul() + u'<li><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></li>\n<li><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></li>\n<li><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></li>\n<li><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></li>' + >>> print f.as_ul() + <li><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></li> + <li><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></li> + <li><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></li> + <li><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></li> + +``as_table()`` +~~~~~~~~~~~~~~ + +Finally, ``Form.as_table()`` outputs the form as an HTML ``<table>``. This is +exactly the same as ``print``. In fact, when you ``print`` a form object, it +calls its ``as_table()`` method behind the scenes:: + + >>> f = ContactForm() + >>> f.as_table() + u'<tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr>\n<tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr>\n<tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr>\n<tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr>' + >>> print f.as_table() + <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr> + <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr> + <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr> + <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr> + +Configuring HTML ``<label>`` tags +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An HTML ``<label>`` tag designates which label text is associated with which +form element. This small enhancement makes forms more usable and more accessible +to assistive devices. It's always a good idea to use ``<label>`` tags. + +By default, the form rendering methods include HTML ``id`` attributes on the +form elements and corresponding ``<label>`` tags around the labels. The ``id`` +attribute values are generated by prepending ``id_`` to the form field names. +This behavior is configurable, though, if you want to change the ``id`` +convention or remove HTML ``id`` attributes and ``<label>`` tags entirely. + +Use the ``auto_id`` argument to the ``Form`` constructor to control the label +and ``id`` behavior. This argument must be ``True``, ``False`` or a string. + +If ``auto_id`` is ``False``, then the form output will not include ``<label>`` +tags nor ``id`` attributes:: + + >>> f = ContactForm(auto_id=False) + >>> print f.as_table() + <tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /></td></tr> + <tr><th>Message:</th><td><input type="text" name="message" /></td></tr> + <tr><th>Sender:</th><td><input type="text" name="sender" /></td></tr> + <tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr> + >>> print f.as_ul() + <li>Subject: <input type="text" name="subject" maxlength="100" /></li> + <li>Message: <input type="text" name="message" /></li> + <li>Sender: <input type="text" name="sender" /></li> + <li>Cc myself: <input type="checkbox" name="cc_myself" /></li> + >>> print f.as_p() + <p>Subject: <input type="text" name="subject" maxlength="100" /></p> + <p>Message: <input type="text" name="message" /></p> + <p>Sender: <input type="text" name="sender" /></p> + <p>Cc myself: <input type="checkbox" name="cc_myself" /></p> + +If ``auto_id`` is set to ``True``, then the form output *will* include +``<label>`` tags and will simply use the field name as its ``id`` for each form +field:: + + >>> f = ContactForm(auto_id=True) + >>> print f.as_table() + <tr><th><label for="subject">Subject:</label></th><td><input id="subject" type="text" name="subject" maxlength="100" /></td></tr> + <tr><th><label for="message">Message:</label></th><td><input type="text" name="message" id="message" /></td></tr> + <tr><th><label for="sender">Sender:</label></th><td><input type="text" name="sender" id="sender" /></td></tr> + <tr><th><label for="cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="cc_myself" /></td></tr> + >>> print f.as_ul() + <li><label for="subject">Subject:</label> <input id="subject" type="text" name="subject" maxlength="100" /></li> + <li><label for="message">Message:</label> <input type="text" name="message" id="message" /></li> + <li><label for="sender">Sender:</label> <input type="text" name="sender" id="sender" /></li> + <li><label for="cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="cc_myself" /></li> + >>> print f.as_p() + <p><label for="subject">Subject:</label> <input id="subject" type="text" name="subject" maxlength="100" /></p> + <p><label for="message">Message:</label> <input type="text" name="message" id="message" /></p> + <p><label for="sender">Sender:</label> <input type="text" name="sender" id="sender" /></p> + <p><label for="cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="cc_myself" /></p> + +If ``auto_id`` is set to a string containing the format character ``'%s'``, +then the form output will include ``<label>`` tags, and will generate ``id`` +attributes based on the format string. For example, for a format string +``'field_%s'``, a field named ``subject`` will get the ``id`` +``'field_subject'``. Continuing our example:: + + >>> f = ContactForm(auto_id='id_for_%s') + >>> print f.as_table() + <tr><th><label for="id_for_subject">Subject:</label></th><td><input id="id_for_subject" type="text" name="subject" maxlength="100" /></td></tr> + <tr><th><label for="id_for_message">Message:</label></th><td><input type="text" name="message" id="id_for_message" /></td></tr> + <tr><th><label for="id_for_sender">Sender:</label></th><td><input type="text" name="sender" id="id_for_sender" /></td></tr> + <tr><th><label for="id_for_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></td></tr> + >>> print f.as_ul() + <li><label for="id_for_subject">Subject:</label> <input id="id_for_subject" type="text" name="subject" maxlength="100" /></li> + <li><label for="id_for_message">Message:</label> <input type="text" name="message" id="id_for_message" /></li> + <li><label for="id_for_sender">Sender:</label> <input type="text" name="sender" id="id_for_sender" /></li> + <li><label for="id_for_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></li> + >>> print f.as_p() + <p><label for="id_for_subject">Subject:</label> <input id="id_for_subject" type="text" name="subject" maxlength="100" /></p> + <p><label for="id_for_message">Message:</label> <input type="text" name="message" id="id_for_message" /></p> + <p><label for="id_for_sender">Sender:</label> <input type="text" name="sender" id="id_for_sender" /></p> + <p><label for="id_for_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></p> + +If ``auto_id`` is set to any other true value -- such as a string that doesn't +include ``%s`` -- then the library will act as if ``auto_id`` is ``True``. + +By default, ``auto_id`` is set to the string ``'id_%s'``. + +Notes on field ordering +~~~~~~~~~~~~~~~~~~~~~~~ + +In the ``as_p()``, ``as_ul()`` and ``as_table()`` shortcuts, the fields are +displayed in the order in which you define them in your form class. For +example, in the ``ContactForm`` example, the fields are defined in the order +``subject``, ``message``, ``sender``, ``cc_myself``. To reorder the HTML +output, just change the order in which those fields are listed in the class. + +How errors are displayed +~~~~~~~~~~~~~~~~~~~~~~~~ + +If you render a bound ``Form`` object, the act of rendering will automatically +run the form's validation if it hasn't already happened, and the HTML output +will include the validation errors as a ``<ul>`` near the field. The particular +positioning of the error messages depends on the output method you're using:: + + >>> data = {'subject': '', + ... 'message': 'Hi there', + ... 'sender': 'invalid e-mail address', + ... 'cc_myself': True} + >>> f = ContactForm(data, auto_id=False) + >>> print f.as_table() + <tr><th>Subject:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="subject" maxlength="100" /></td></tr> + <tr><th>Message:</th><td><input type="text" name="message" value="Hi there" /></td></tr> + <tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul><input type="text" name="sender" value="invalid e-mail address" /></td></tr> + <tr><th>Cc myself:</th><td><input checked="checked" type="checkbox" name="cc_myself" /></td></tr> + >>> print f.as_ul() + <li><ul class="errorlist"><li>This field is required.</li></ul>Subject: <input type="text" name="subject" maxlength="100" /></li> + <li>Message: <input type="text" name="message" value="Hi there" /></li> + <li><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul>Sender: <input type="text" name="sender" value="invalid e-mail address" /></li> + <li>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></li> + >>> print f.as_p() + <p><ul class="errorlist"><li>This field is required.</li></ul></p> + <p>Subject: <input type="text" name="subject" maxlength="100" /></p> + <p>Message: <input type="text" name="message" value="Hi there" /></p> + <p><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul></p> + <p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p> + <p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p> + +More granular output +~~~~~~~~~~~~~~~~~~~~ + +The ``as_p()``, ``as_ul()`` and ``as_table()`` methods are simply shortcuts for +lazy developers -- they're not the only way a form object can be displayed. + +To display the HTML for a single field in your form, use dictionary lookup +syntax using the field's name as the key, and print the resulting object:: + + >>> f = ContactForm() + >>> print f['subject'] + <input id="id_subject" type="text" name="subject" maxlength="100" /> + >>> print f['message'] + <input type="text" name="message" id="id_message" /> + >>> print f['sender'] + <input type="text" name="sender" id="id_sender" /> + >>> print f['cc_myself'] + <input type="checkbox" name="cc_myself" id="id_cc_myself" /> + +Call ``str()`` or ``unicode()`` on the field to get its rendered HTML as a +string or Unicode object, respectively:: + + >>> str(f['subject']) + '<input id="id_subject" type="text" name="subject" maxlength="100" />' + >>> unicode(f['subject']) + u'<input id="id_subject" type="text" name="subject" maxlength="100" />' + +The field-specific output honors the form object's ``auto_id`` setting:: + + >>> f = ContactForm(auto_id=False) + >>> print f['message'] + <input type="text" name="message" /> + >>> f = ContactForm(auto_id='id_%s') + >>> print f['message'] + <input type="text" name="message" id="id_message" /> + +For a field's list of errors, access the field's ``errors`` attribute. This +is a list-like object that is displayed as an HTML ``<ul>`` when printed:: + + >>> data = {'subject': 'hi', 'message': '', 'sender': '', 'cc_myself': ''} + >>> f = ContactForm(data, auto_id=False) + >>> print f['message'] + <input type="text" name="message" /> + >>> f['message'].errors + [u'This field is required.'] + >>> print f['message'].errors + <ul class="errorlist"><li>This field is required.</li></ul> + >>> f['subject'].errors + [] + >>> print f['subject'].errors + + >>> str(f['subject'].errors) + '' + +Fields +====== + +When you create a ``Form`` class, the most important part is defining the +fields of the form. Each field has custom validation logic, along with a few +other hooks. + +Although the primary way you'll use ``Field`` classes is in ``Form`` classes, +you can also instantiate them and use them directly to get a better idea of +how they work. Each ``Field`` instance has a ``clean()`` method, which takes +a single argument and either raises a ``django.newforms.ValidationError`` +exception or returns the clean value:: + + >>> f = forms.EmailField() + >>> f.clean('foo@example.com') + u'foo@example.com' + >>> f.clean(u'foo@example.com') + u'foo@example.com' + >>> f.clean('invalid e-mail address') + Traceback (most recent call last): + ... + ValidationError: [u'Enter a valid e-mail address.'] + +If you've used Django's old forms/validation framework, take care in noticing +this ``ValidationError`` is different than the previous ``ValidationError``. +This one lives at ``django.newforms.ValidationError`` rather than +``django.core.validators.ValidationError``. + +Core field arguments +-------------------- + +Each ``Field`` class constructor takes at least these arguments. Some +``Field`` classes take additional, field-specific arguments, but the following +should *always* be available: + +``required`` +~~~~~~~~~~~~ + +By default, each ``Field`` class assumes the value is required, so if you pass +an empty value -- either ``None`` or the empty string (``""``) -- then +``clean()`` will raise a ``ValidationError`` exception:: + + >>> f = forms.CharField() + >>> f.clean('foo') + u'foo' + >>> f.clean('') + Traceback (most recent call last): + ... + ValidationError: [u'This field is required.'] + >>> f.clean(None) + Traceback (most recent call last): + ... + ValidationError: [u'This field is required.'] + >>> f.clean(' ') + u' ' + >>> f.clean(0) + u'0' + >>> f.clean(True) + u'True' + >>> f.clean(False) + u'False' + +To specify that a field is *not* required, pass ``required=False`` to the +``Field`` constructor:: + + >>> f = forms.CharField(required=False) + >>> f.clean('foo') + u'foo' + >>> f.clean('') + u'' + >>> f.clean(None) + u'' + >>> f.clean(0) + u'0' + >>> f.clean(True) + u'True' + >>> f.clean(False) + u'False' + +If a ``Field`` has ``required=False`` and you pass ``clean()`` an empty value, +then ``clean()`` will return a *normalized* empty value rather than raising +``ValidationError``. For ``CharField``, this will be a Unicode empty string. +For other ``Field`` classes, it might be ``None``. (This varies from field to +field.) + +``label`` +~~~~~~~~~ + +The ``label`` argument lets you specify the "human-friendly" label for this +field. This is used when the ``Field`` is displayed in a ``Form``. + +As explained in _`Outputting forms as HTML` above, the default label for a +``Field`` is generated from the field name by converting all underscores to +spaces and upper-casing the first letter. Specify ``label`` if that default +behavior doesn't result in an adequate label. + +Here's a full example ``Form`` that implements ``label`` for two of its fields. +We've specified ``auto_id=False`` to simplify the output:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField(label='Your name') + ... url = forms.URLField(label='Your Web site', required=False) + ... comment = forms.CharField() + >>> f = CommentForm(auto_id=False) + >>> print f + <tr><th>Your name:</th><td><input type="text" name="name" /></td></tr> + <tr><th>Your Web site:</th><td><input type="text" name="url" /></td></tr> + <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr> + +``initial`` +~~~~~~~~~~~ + +The ``initial`` argument lets you specify the initial value to use when +rendering this ``Field`` in an unbound ``Form``. + +The use-case for this is when you want to display an "empty" form in which a +field is initialized to a particular value. For example:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField(initial='Your name') + ... url = forms.URLField(initial='http://') + ... comment = forms.CharField() + >>> f = CommentForm(auto_id=False) + >>> print f + <tr><th>Name:</th><td><input type="text" name="name" value="Your name" /></td></tr> + <tr><th>Url:</th><td><input type="text" name="url" value="http://" /></td></tr> + <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr> + +You may be thinking, why not just pass a dictionary of the initial values as +data when displaying the form? Well, if you do that, you'll trigger validation, +and the HTML output will include any validation errors:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField() + ... url = forms.URLField() + ... comment = forms.CharField() + >>> default_data = {'name': 'Your name', 'url': 'http://'} + >>> f = CommentForm(default_data, auto_id=False) + >>> print f + <tr><th>Name:</th><td><input type="text" name="name" value="Your name" /></td></tr> + <tr><th>Url:</th><td><ul class="errorlist"><li>Enter a valid URL.</li></ul><input type="text" name="url" value="http://" /></td></tr> + <tr><th>Comment:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="comment" /></td></tr> + +This is why ``initial`` values are only displayed for unbound forms. For bound +forms, the HTML output will use the bound data. + +Also note that ``initial`` values are *not* used as "fallback" data in +validation if a particular field's value is not given. ``initial`` values are +*only* intended for initial form display:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField(initial='Your name') + ... url = forms.URLField(initial='http://') + ... comment = forms.CharField() + >>> data = {'name': '', 'url': '', 'comment': 'Foo'} + >>> f = CommentForm(data) + >>> f.is_valid() + False + # The form does *not* fall back to using the initial values. + >>> f.errors + {'url': [u'This field is required.'], 'name': [u'This field is required.']} + +``widget`` +~~~~~~~~~~ + +The ``widget`` argument lets you specify a ``Widget`` class to use when +rendering this ``Field``. See _`Widgets` below for more information. + +``help_text`` +~~~~~~~~~~~~~ + +The ``help_text`` argument lets you specify descriptive text for this +``Field``. If you provide ``help_text``, it will be displayed next to the +``Field`` when the ``Field`` is rendered in a ``Form``. + +Here's a full example ``Form`` that implements ``help_text`` for two of its +fields. We've specified ``auto_id=False`` to simplify the output:: + + >>> class HelpTextContactForm(forms.Form): + ... subject = forms.CharField(max_length=100, help_text='100 characters max.') + ... message = forms.CharField() + ... sender = forms.EmailField(help_text='A valid e-mail address, please.') + ... cc_myself = forms.BooleanField() + >>> f = HelpTextContactForm(auto_id=False) + >>> print f.as_table() + <tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /><br />100 characters max.</td></tr> + <tr><th>Message:</th><td><input type="text" name="message" /></td></tr> + <tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid e-mail address, please.</td></tr> + <tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr> + >>> print f.as_ul() + <li>Subject: <input type="text" name="subject" maxlength="100" /> 100 characters max.</li> + <li>Message: <input type="text" name="message" /></li> + <li>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</li> + <li>Cc myself: <input type="checkbox" name="cc_myself" /></li> + >>> print f.as_p() + <p>Subject: <input type="text" name="subject" maxlength="100" /> 100 characters max.</p> + <p>Message: <input type="text" name="message" /></p> + <p>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</p> + <p>Cc myself: <input type="checkbox" name="cc_myself" /></p> + +Dynamic initial values +---------------------- + +The ``initial`` argument to ``Field`` (explained above) lets you hard-code the +initial value for a ``Field`` -- but what if you want to declare the initial +value at runtime? For example, you might want to fill in a ``username`` field +with the username of the current session. + +To accomplish this, use the ``initial`` argument to a ``Form``. This argument, +if given, should be a dictionary mapping field names to initial values. Only +include the fields for which you're specifying an initial value; it's not +necessary to include every field in your form. For example:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField() + ... url = forms.URLField() + ... comment = forms.CharField() + >>> f = CommentForm(initial={'name': 'your username'}, auto_id=False) + >>> print f + <tr><th>Name:</th><td><input type="text" name="name" value="your username" /></td></tr> + <tr><th>Url:</th><td><input type="text" name="url" /></td></tr> + <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr> + >>> f = CommentForm(initial={'name': 'another username'}, auto_id=False) + >>> print f + <tr><th>Name:</th><td><input type="text" name="name" value="another username" /></td></tr> + <tr><th>Url:</th><td><input type="text" name="url" /></td></tr> + <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr> + +Just like the ``initial`` parameter to ``Field``, these values are only +displayed for unbound forms, and they're not used as fallback values if a +particular value isn't provided. + +Finally, note that if a ``Field`` defines ``initial`` *and* you include +``initial`` when instantiating the ``Form``, then the latter ``initial`` will +have precedence. In this example, ``initial`` is provided both at the field +level and at the form instance level, and the latter gets precedence:: + + >>> class CommentForm(forms.Form): + ... name = forms.CharField(initial='class') + ... url = forms.URLField() + ... comment = forms.CharField() + >>> f = CommentForm(initial={'name': 'instance'}, auto_id=False) + >>> print f + <tr><th>Name:</th><td><input type="text" name="name" value="instance" /></td></tr> + <tr><th>Url:</th><td><input type="text" name="url" /></td></tr> + <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr> More coming soon ================ @@ -77,3 +825,9 @@ That's all the documentation for now. For more, see the file http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py -- the unit tests for ``django.newforms``. This can give you a good idea of what's possible. + +If you're really itching to learn and use this library, please be patient. +We're working hard on finishing both the code and documentation. + +Widgets +======= diff --git a/docs/outputting_csv.txt b/docs/outputting_csv.txt index 1970261891..d6ec3f62a0 100644 --- a/docs/outputting_csv.txt +++ b/docs/outputting_csv.txt @@ -24,7 +24,7 @@ and Django's ``HttpResponse`` objects are file-like objects. For more information on the CSV library, see the `CSV library docs`_. - .. _Request and response objects: http://www.djangoproject.com/documentation/request_response/ + .. _Request and response objects: ../request_response/ .. _CSV library docs: http://www.python.org/doc/current/lib/module-csv.html Here's an example:: @@ -115,5 +115,5 @@ a line of CSV for each row. It uses the `addslashes template filter`_ to ensure there aren't any problems with quotes. If you can be certain your data doesn't have single or double quotes in it, you can remove the ``addslashes`` filters. -.. _Django template system: http://www.djangoproject.com/documentation/templates/ -.. _addslashes template filter: http://www.djangoproject.com/documentation/templates/#addslashes +.. _Django template system: ../templates/ +.. _addslashes template filter: ../templates/#addslashes diff --git a/docs/outputting_pdf.txt b/docs/outputting_pdf.txt index edd34aca24..464bf7fcb8 100644 --- a/docs/outputting_pdf.txt +++ b/docs/outputting_pdf.txt @@ -43,7 +43,7 @@ objects. For more information on ``HttpResponse`` objects, see `Request and response objects`_. - .. _Request and response objects: http://www.djangoproject.com/documentation/request_response/ + .. _Request and response objects: ../request_response/ Here's a "Hello World" example:: diff --git a/docs/overview.txt b/docs/overview.txt index 8e6274dd9a..35af75bf05 100644 --- a/docs/overview.txt +++ b/docs/overview.txt @@ -11,7 +11,7 @@ understand how Django works, but this isn't intended to be a tutorial or reference. Please see our more-detailed Django documentation_ when you're ready to start a project. -.. _documentation: http://www.djangoproject.com/documentation/ +.. _documentation: ../ Design your model ================= diff --git a/docs/redirects.txt b/docs/redirects.txt index e0bcb2f1fa..5f84f28097 100644 --- a/docs/redirects.txt +++ b/docs/redirects.txt @@ -15,8 +15,8 @@ To install the redirects app, follow these steps: to your MIDDLEWARE_CLASSES_ setting. 3. Run the command ``manage.py syncdb``. -.. _INSTALLED_APPS: http://www.djangoproject.com/documentation/settings/#installed-apps -.. _MIDDLEWARE_CLASSES: http://www.djangoproject.com/documentation/settings/#middleware-classes +.. _INSTALLED_APPS: ../settings/#installed-apps +.. _MIDDLEWARE_CLASSES: ../settings/#middleware-classes How it works ============ @@ -46,8 +46,8 @@ resort. For more on middleware, read the `middleware docs`_. -.. _SITE_ID: http://www.djangoproject.com/documentation/settings/#site-id -.. _middleware docs: http://www.djangoproject.com/documentation/middleware/ +.. _SITE_ID: ../settings/#site-id +.. _middleware docs: ../middleware/ How to add, change and delete redirects ======================================= @@ -63,9 +63,9 @@ Via the Python API ------------------ Redirects are represented by a standard `Django model`_, which lives in -`django/contrib/redirects/models/redirects.py`_. You can access redirect +`django/contrib/redirects/models.py`_. You can access redirect objects via the `Django database API`_. -.. _Django model: http://www.djangoproject.com/documentation/model_api/ -.. _django/contrib/redirects/models/redirects.py: http://code.djangoproject.com/browser/django/trunk/django/contrib/redirects/models/redirects.py -.. _Django database API: http://www.djangoproject.com/documentation/db_api/ +.. _Django model: ../model_api/ +.. _django/contrib/redirects/models.py: http://code.djangoproject.com/browser/django/trunk/django/contrib/redirects/models.py +.. _Django database API: ../db_api/ diff --git a/docs/request_response.txt b/docs/request_response.txt index 006ac6b648..afea0bcd53 100644 --- a/docs/request_response.txt +++ b/docs/request_response.txt @@ -117,14 +117,14 @@ All attributes except ``session`` should be considered read-only. ``AuthenticationMiddleware`` activated. For more, see `Authentication in Web requests`_. - .. _Authentication in Web requests: http://www.djangoproject.com/documentation/authentication/#authentication-in-web-requests + .. _Authentication in Web requests: ../authentication/#authentication-in-web-requests ``session`` A readable-and-writable, dictionary-like object that represents the current session. This is only available if your Django installation has session support activated. See the `session documentation`_ for full details. - .. _`session documentation`: http://www.djangoproject.com/documentation/sessions/ + .. _`session documentation`: ../sessions/ ``raw_post_data`` The raw HTTP POST data. This is only useful for advanced processing. Use diff --git a/docs/sessions.txt b/docs/sessions.txt index dd4a581d91..8c54c1634a 100644 --- a/docs/sessions.txt +++ b/docs/sessions.txt @@ -27,7 +27,7 @@ If you don't want to use sessions, you might as well remove the ``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and ``'django.contrib.sessions'`` from your ``INSTALLED_APPS``. It'll save you a small bit of overhead. -.. _middleware: http://www.djangoproject.com/documentation/middleware/ +.. _middleware: ../middleware/ Using sessions in views ======================= @@ -217,6 +217,23 @@ browser-length cookies -- cookies that expire as soon as the user closes his or her browser. Use this if you want people to have to log in every time they open a browser. +Clearing the session table +========================== + +Note that session data can accumulate in the ``django_session`` database table +and Django does *not* provide automatic purging. Therefore, it's your job to +purge expired sessions on a regular basis. + +To understand this problem, consider what happens when a user uses a session. +When a user logs in, Django adds a row to the ``django_session`` database +table. Django updates this row each time the session data changes. If the user +logs out manually, Django deletes the row. But if the user does *not* log out, +the row never gets deleted. + +Django provides a sample clean-up script in ``django/bin/daily_cleanup.py``. +That script deletes any session in the session table whose ``expire_date`` is +in the past -- but your application may have different requirements. + Settings ======== @@ -273,7 +290,7 @@ Whether to save the session data on every request. If this is ``False`` (default), then the session data will only be saved if it has been modified -- that is, if any of its dictionary values have been assigned or deleted. -.. _Django settings: http://www.djangoproject.com/documentation/settings/ +.. _Django settings: ../settings/ Technical details ================= diff --git a/docs/settings.txt b/docs/settings.txt index 00672060db..cdf440ed6b 100644 --- a/docs/settings.txt +++ b/docs/settings.txt @@ -59,7 +59,7 @@ Use the ``--settings`` command-line argument to specify the settings manually:: django-admin.py runserver --settings=mysite.settings -.. _django-admin.py: http://www.djangoproject.com/documentation/django_admin/ +.. _django-admin.py: ../django_admin/ On the server (mod_python) -------------------------- @@ -75,7 +75,7 @@ settings file to use. Do that with ``SetEnv``:: Read the `Django mod_python documentation`_ for more information. -.. _Django mod_python documentation: http://www.djangoproject.com/documentation/modpython/ +.. _Django mod_python documentation: ../modpython/ Default settings ================ @@ -102,7 +102,7 @@ between the current settings file and Django's default settings. For more, see the `diffsettings documentation`_. -.. _diffsettings documentation: http://www.djangoproject.com/documentation/django_admin/#diffsettings +.. _diffsettings documentation: ../django_admin/#diffsettings Using settings in Python code ============================= @@ -157,13 +157,13 @@ ABSOLUTE_URL_OVERRIDES Default: ``{}`` (Empty dictionary) -A dictionary mapping ``"app_label.module_name"`` strings to functions that take +A dictionary mapping ``"app_label.model_name"`` strings to functions that take a model object and return its URL. This is a way of overriding ``get_absolute_url()`` methods on a per-installation basis. Example:: ABSOLUTE_URL_OVERRIDES = { - 'blogs.blogs': lambda o: "/blogs/%s/" % o.slug, - 'news.stories': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), + 'blogs.Weblog': lambda o: "/blogs/%s/" % o.slug, + 'news.Story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), } ADMIN_FOR @@ -306,7 +306,7 @@ pages -- and, possibly, by other parts of the system. See See also DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT. -.. _allowed date format strings: http://www.djangoproject.com/documentation/templates/#now +.. _allowed date format strings: ../templates/#now DATETIME_FORMAT --------------- @@ -319,7 +319,7 @@ pages -- and, possibly, by other parts of the system. See See also DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT. -.. _allowed date format strings: http://www.djangoproject.com/documentation/templates/#now +.. _allowed date format strings: ../templates/#now DEBUG ----- @@ -433,7 +433,7 @@ A tuple of strings designating all applications that are enabled in this Django installation. Each string should be a full Python path to a Python package that contains a Django application, as created by `django-admin.py startapp`_. -.. _django-admin.py startapp: http://www.djangoproject.com/documentation/django_admin/#startapp-appname +.. _django-admin.py startapp: ../django_admin/#startapp-appname INTERNAL_IPS ------------ @@ -464,7 +464,7 @@ A string representing the language code for this installation. This should be in standard language format. For example, U.S. English is ``"en-us"``. See the `internationalization docs`_. -.. _internationalization docs: http://www.djangoproject.com/documentation/i18n/ +.. _internationalization docs: ../i18n/ LANGUAGES --------- @@ -557,6 +557,11 @@ Default: ``''`` (Empty string) URL that handles the media served from ``MEDIA_ROOT``. Example: ``"http://media.lawrence.com"`` +Note that this should have a trailing slash if it has a path component. + +Good: ``"http://www.example.com/static/"`` +Bad: ``"http://www.example.com/static"`` + MIDDLEWARE_CLASSES ------------------ @@ -612,7 +617,7 @@ Default: Not defined A string representing the full Python import path to your root URLconf. For example: ``"mydjangoapps.urls"``. See `How Django processes a request`_. -.. _How Django processes a request: http://www.djangoproject.com/documentation/url_dispatch/#how-django-processes-a-request +.. _How Django processes a request: ../url_dispatch/#how-django-processes-a-request SECRET_KEY ---------- @@ -704,7 +709,7 @@ and a single database can manage content for multiple sites. See the `site framework docs`_. -.. _site framework docs: http://www.djangoproject.com/documentation/sites/ +.. _site framework docs: ../sites/ TEMPLATE_CONTEXT_PROCESSORS --------------------------- @@ -760,7 +765,7 @@ Default: ``''`` (Empty string) Output, as a string, that the template system should use for invalid (e.g. misspelled) variables. See `How invalid variables are handled`_. -.. _How invalid variables are handled: http://www.djangoproject.com/documentation/templates_python/#how-invalid-variables-are-handled +.. _How invalid variables are handled: ../templates_python/#how-invalid-variables-are-handled TEST_RUNNER ----------- @@ -798,7 +803,7 @@ pages -- and, possibly, by other parts of the system. See See also DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT. -.. _allowed date format strings: http://www.djangoproject.com/documentation/templates/#now +.. _allowed date format strings: ../templates/#now TIME_ZONE --------- @@ -868,11 +873,11 @@ Different locales have different formats. For example, U.S. English would say See `allowed date format strings`_. See also DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT and MONTH_DAY_FORMAT. -.. _cache docs: http://www.djangoproject.com/documentation/cache/ -.. _middleware docs: http://www.djangoproject.com/documentation/middleware/ -.. _session docs: http://www.djangoproject.com/documentation/sessions/ -.. _See available choices: http://www.postgresql.org/docs/current/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE -.. _template documentation: http://www.djangoproject.com/documentation/templates_python/ +.. _cache docs: ../cache/ +.. _middleware docs: ../middleware/ +.. _session docs: ../sessions/ +.. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE +.. _template documentation: ../templates_python/ Creating your own settings ========================== diff --git a/docs/sitemaps.txt b/docs/sitemaps.txt index 7414567b16..dafc009859 100644 --- a/docs/sitemaps.txt +++ b/docs/sitemaps.txt @@ -23,8 +23,8 @@ you express this information in Python code. It works much like Django's `syndication framework`_. To create a sitemap, just write a ``Sitemap`` class and point to it in your URLconf_. -.. _syndication framework: http://www.djangoproject.com/documentation/syndication/ -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ +.. _syndication framework: ../syndication/ +.. _URLconf: ../url_dispatch/ Installation ============ @@ -41,9 +41,9 @@ To install the sitemap app, follow these steps: reason it needs to go into ``INSTALLED_APPS`` is so that the ``load_template_source`` template loader can find the default templates.) -.. _INSTALLED_APPS: http://www.djangoproject.com/documentation/settings/#installed-apps -.. _TEMPLATE_LOADERS: http://www.djangoproject.com/documentation/settings/#template-loaders -.. _sites framework: http://www.djangoproject.com/documentation/sites/ +.. _INSTALLED_APPS: ../settings/#installed-apps +.. _TEMPLATE_LOADERS: ../settings/#template-loaders +.. _sites framework: ../sites/ Initialization ============== @@ -68,7 +68,7 @@ The sitemap view takes an extra, required argument: ``{'sitemaps': sitemaps}``. ``NewsSitemap``). It may also map to an *instance* of a ``Sitemap`` class (e.g., ``BlogSitemap(some_var)``). -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ +.. _URLconf: ../url_dispatch/ Sitemap classes =============== @@ -217,8 +217,8 @@ defined for the current ``SITE_ID`` (see the `sites documentation`_) and creates an entry in the sitemap. These entries include only the ``location`` attribute -- not ``lastmod``, ``changefreq`` or ``priority``. -.. _flatpages: http://www.djangoproject.com/documentation/flatpages/ -.. _sites documentation: http://www.djangoproject.com/documentation/sites/ +.. _flatpages: ../flatpages/ +.. _sites documentation: ../sites/ ``GenericSitemap`` ------------------ @@ -232,7 +232,7 @@ the ``lastmod`` attribute in the generated sitemap. You may also pass ``priority`` and ``changefreq`` keyword arguments to the ``GenericSitemap`` constructor to specify these attributes for all URLs. -.. _generic views: http://www.djangoproject.com/documentation/generic_views/ +.. _generic views: ../generic_views/ Example ------- @@ -261,7 +261,7 @@ Here's an example of a URLconf_ using both:: (r'^sitemap.xml$', 'django.contrib.sitemaps.views.sitemap', {'sitemaps': sitemaps}) ) -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ +.. _URLconf: ../url_dispatch/ Creating a sitemap index ======================== diff --git a/docs/sites.txt b/docs/sites.txt index 8c5f1fc64b..7497d7dd80 100644 --- a/docs/sites.txt +++ b/docs/sites.txt @@ -276,8 +276,8 @@ you want your admin site to have access to all objects (not just site-specific ones), put ``objects = models.Manager()`` in your model, before you define ``CurrentSiteManager``. -.. _manager: http://www.djangoproject.com/documentation/model_api/#managers -.. _manager documentation: http://www.djangoproject.com/documentation/model_api/#managers +.. _manager: ../model_api/#managers +.. _manager documentation: ../model_api/#managers How Django uses the sites framework =================================== @@ -316,7 +316,7 @@ Here's how Django uses the sites framework: * The shortcut view (``django.views.defaults.shortcut``) uses the domain of the current ``Site`` object when calculating an object's URL. -.. _redirects framework: http://www.djangoproject.com/documentation/redirects/ -.. _flatpages framework: http://www.djangoproject.com/documentation/flatpages/ -.. _syndication framework: http://www.djangoproject.com/documentation/syndication/ -.. _authentication framework: http://www.djangoproject.com/documentation/authentication/ +.. _redirects framework: ../redirects/ +.. _flatpages framework: ../flatpages/ +.. _syndication framework: ../syndication/ +.. _authentication framework: ../authentication/ diff --git a/docs/static_files.txt b/docs/static_files.txt index 55380a659b..b6a1d278fd 100644 --- a/docs/static_files.txt +++ b/docs/static_files.txt @@ -24,7 +24,7 @@ production setting. Use this only for development. For information on serving static files in an Apache production environment, see the `Django mod_python documentation`_. -.. _Django mod_python documentation: http://www.djangoproject.com/documentation/modpython/#serving-media-files +.. _Django mod_python documentation: ../modpython/#serving-media-files How to do it ============ @@ -49,7 +49,7 @@ Examples: * The file ``/path/bar.jpg`` will not be accessible, because it doesn't fall under the document root. -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ +.. _URLconf: ../url_dispatch/ Directory listings ================== @@ -122,4 +122,4 @@ associated with the ``django.views.static.serve`` view. If not Of course, the catch here is that you'll have to remember to set ``DEBUG=False`` in your production settings file. But you should be doing that anyway. -.. _DEBUG setting: http://www.djangoproject.com/documentation/settings/#debug +.. _DEBUG setting: ../settings/#debug diff --git a/docs/syndication_feeds.txt b/docs/syndication_feeds.txt index 59a9022d9b..72b05ff16a 100644 --- a/docs/syndication_feeds.txt +++ b/docs/syndication_feeds.txt @@ -26,7 +26,7 @@ to determine which feed to output. To create a feed, just write a ``Feed`` class and point to it in your URLconf_. -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ +.. _URLconf: ../url_dispatch/ Initialization -------------- @@ -72,8 +72,8 @@ The above example registers two feeds: Once that's set up, you just need to define the ``Feed`` classes themselves. -.. _URLconf: http://www.djangoproject.com/documentation/url_dispatch/ -.. _settings file: http://www.djangoproject.com/documentation/settings/ +.. _URLconf: ../url_dispatch/ +.. _settings file: ../settings/ Feed classes ------------ @@ -156,8 +156,8 @@ put into those elements. {{ obj.description }} .. _chicagocrime.org: http://www.chicagocrime.org/ -.. _object-relational mapper: http://www.djangoproject.com/documentation/db_api/ -.. _Django templates: http://www.djangoproject.com/documentation/templates/ +.. _object-relational mapper: ../db_api/ +.. _Django templates: ../templates/ A complex example ----------------- @@ -277,7 +277,7 @@ Feeds created by the syndication framework automatically include the appropriate ``<language>`` tag (RSS 2.0) or ``xml:lang`` attribute (Atom). This comes directly from your `LANGUAGE_CODE setting`_. -.. _LANGUAGE_CODE setting: http://www.djangoproject.com/documentation/settings/#language-code +.. _LANGUAGE_CODE setting: ../settings/#language-code URLs ---- @@ -292,7 +292,7 @@ Atom feeds require a ``<link rel="self">`` that defines the feed's current location. The syndication framework populates this automatically, using the domain of the current site according to the SITE_ID setting. -.. _SITE_ID setting: http://www.djangoproject.com/documentation/settings/#site-id +.. _SITE_ID setting: ../settings/#site-id Publishing Atom and RSS feeds in tandem --------------------------------------- diff --git a/docs/templates.txt b/docs/templates.txt index b4cc47b9f3..9f8fe446b4 100644 --- a/docs/templates.txt +++ b/docs/templates.txt @@ -792,7 +792,7 @@ Note that if you use ``{% ssi %}``, you'll need to define See also: ``{% include %}``. -.. _ALLOWED_INCLUDE_ROOTS: http://www.djangoproject.com/documentation/settings/#allowed-include-roots +.. _ALLOWED_INCLUDE_ROOTS: ../settings/#allowed-include-roots templatetag ~~~~~~~~~~~ @@ -924,13 +924,31 @@ Replaces ampersands with ``&`` entities. floatformat ~~~~~~~~~~~ -Rounds a floating-point number to one decimal place -- but only if there's a -decimal part to be displayed. For example: +When used without an argument, rounds a floating-point number to one decimal +place -- but only if there's a decimal part to be displayed. For example: * ``36.123`` gets converted to ``36.1`` * ``36.15`` gets converted to ``36.2`` * ``36`` gets converted to ``36`` +**New in Django development version** + +If used with a numeric integer argument, ``floatformat`` rounds a number to that +many decimal places. For example: + + * ``36.1234`` with floatformat:3 gets converted to ``36.123`` + * ``36`` with floatformat:4 gets converted to ``36.0000`` + +If the argument passed to ``floatformat`` is negative, it will round a number to +that many decimal places -- but only if there's a decimal part to be displayed. +For example: + + * ``36.1234`` with floatformat:-3 gets converted to ``36.123`` + * ``36`` with floatformat:-4 gets converted to ``36`` + +Using ``floatformat`` with no argument is equivalent to using ``floatformat`` with +an argument of ``-1``. + get_digit ~~~~~~~~~ @@ -1200,7 +1218,7 @@ django.contrib.humanize A set of Django template filters useful for adding a "human touch" to data. See the `humanize documentation`_. -.. _humanize documentation: http://www.djangoproject.com/documentation/add_ons/#humanize +.. _humanize documentation: ../add_ons/#humanize django.contrib.markup --------------------- diff --git a/docs/templates_python.txt b/docs/templates_python.txt index 7aeed935b9..5f9c5bde43 100644 --- a/docs/templates_python.txt +++ b/docs/templates_python.txt @@ -11,7 +11,7 @@ If you're looking to use the Django template system as part of another application -- i.e., without the rest of the framework -- make sure to read the `configuration`_ section later in this document. -.. _`The Django template language: For template authors`: http://www.djangoproject.com/documentation/templates/ +.. _`The Django template language: For template authors`: ../templates/ Basics ====== @@ -327,8 +327,8 @@ Note:: Here's what each of the default processors does: -.. _HttpRequest object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects -.. _TEMPLATE_CONTEXT_PROCESSORS setting: http://www.djangoproject.com/documentation/settings/#template-context-processors +.. _HttpRequest object: ../request_response/#httprequest-objects +.. _TEMPLATE_CONTEXT_PROCESSORS setting: ../settings/#template-context-processors django.core.context_processors.auth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -353,9 +353,9 @@ If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every permissions that the currently logged-in user has. See the `permissions docs`_. -.. _user authentication docs: http://www.djangoproject.com/documentation/authentication/#users -.. _message docs: http://www.djangoproject.com/documentation/authentication/#messages -.. _permissions docs: http://www.djangoproject.com/documentation/authentication/#permissions +.. _user authentication docs: ../authentication/#users +.. _message docs: ../authentication/#messages +.. _permissions docs: ../authentication/#permissions django.core.context_processors.debug ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -383,9 +383,9 @@ If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every See the `internationalization docs`_ for more. -.. _LANGUAGES setting: http://www.djangoproject.com/documentation/settings/#languages -.. _LANGUAGE_CODE setting: http://www.djangoproject.com/documentation/settings/#language-code -.. _internationalization docs: http://www.djangoproject.com/documentation/i18n/ +.. _LANGUAGES setting: ../settings/#languages +.. _LANGUAGE_CODE setting: ../settings/#language-code +.. _internationalization docs: ../i18n/ django.core.context_processors.request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -944,7 +944,7 @@ The ``takes_context`` parameter defaults to ``False``. When it's set to *True*, the tag is passed the context object, as in this example. That's the only difference between this case and the previous ``inclusion_tag`` example. -.. _tutorials: http://www.djangoproject.com/documentation/tutorial1/#creating-models +.. _tutorials: ../tutorial1/#creating-models Setting a variable in the context ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1115,5 +1115,5 @@ settings you wish to specify. You might want to consider setting at least `settings documentation`_, and any setting starting with *TEMPLATE_* is of obvious interest. -.. _settings file: http://www.djangoproject.com/documentation/settings/#using-settings-without-the-django-settings-module-environment-variable -.. _settings documentation: http://www.djangoproject.com/documentation/settings/ +.. _settings file: ../settings/#using-settings-without-the-django-settings-module-environment-variable +.. _settings documentation: ../settings/ diff --git a/docs/testing.txt b/docs/testing.txt index a0b8a8a187..e7c1a3b161 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -13,7 +13,7 @@ changed unexpectedly as a result of the refactor. Testing a web application is a complex task, as there are many components of a web application that must be validated and tested. To help you test your application, Django provides a test execution -framework, and range of utilities that can be used to stimulate and +framework, and range of utilities that can be used to simulate and inspect various facets of a web application. This testing framework is currently under development, and may change @@ -220,7 +220,7 @@ can be invoked on the ``Client`` instance. will result in the evaluation of a GET request equivalent to:: - http://yoursite.com/customers/details/?name='fred'&age=7 + http://yoursite.com/customers/details/?name=fred&age=7 ``post(path, data={})`` Make a POST request on the provided ``path``. The key-value pairs in the @@ -244,11 +244,11 @@ can be invoked on the ``Client`` instance. ``login(path, username, password)`` In a production site, it is likely that some views will be protected with - the @login_required URL provided by ``django.contrib.auth``. Interacting + the @login_required decorator provided by ``django.contrib.auth``. Interacting with a URL that has been login protected is a slightly complex operation, - so the Test Client provides a simple URL to automate the login process. A + so the Test Client provides a simple method to automate the login process. A call to ``login()`` stimulates the series of GET and POST calls required - to log a user into a @login_required protected URL. + to log a user into a @login_required protected view. If login is possible, the final return value of ``login()`` is the response that is generated by issuing a GET request on the protected URL. If login @@ -415,7 +415,7 @@ arguments: tested. This is the same format returned by ``django.db.models.get_apps()`` Verbosity determines the amount of notification and debug information that - will be printed to the console; '0' is no output, '1' is normal output, + will be printed to the console; `0` is no output, `1` is normal output, and `2` is verbose output. Testing utilities diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt index 1113b603da..1b241f728a 100644 --- a/docs/tutorial01.txt +++ b/docs/tutorial01.txt @@ -17,7 +17,7 @@ installed by running the Python interactive interpreter and typing ``import django``. If that command runs successfully, with no errors, Django is installed. -.. _`Django installed`: http://www.djangoproject.com/documentation/install/ +.. _`Django installed`: ../install/ Creating a project ================== @@ -108,7 +108,7 @@ It worked! Full docs for the development server are at `django-admin documentation`_. -.. _django-admin documentation: http://www.djangoproject.com/documentation/django_admin/ +.. _django-admin documentation: ../django_admin/ Database setup -------------- @@ -378,7 +378,7 @@ as you like, and it will only ever create the tables that don't exist. Read the `django-admin.py documentation`_ for full information on what the ``manage.py`` utility can do. -.. _django-admin.py documentation: http://www.djangoproject.com/documentation/django_admin/ +.. _django-admin.py documentation: ../django_admin/ Playing with the API ==================== @@ -555,5 +555,5 @@ For full details on the database API, see our `Database API reference`_. When you're comfortable with the API, read `part 2 of this tutorial`_ to get Django's automatic admin working. -.. _Database API reference: http://www.djangoproject.com/documentation/db_api/ -.. _part 2 of this tutorial: http://www.djangoproject.com/documentation/tutorial2/ +.. _Database API reference: ../db_api/ +.. _part 2 of this tutorial: ../tutorial2/ diff --git a/docs/tutorial02.txt b/docs/tutorial02.txt index f6d4045fa3..2eabae96f0 100644 --- a/docs/tutorial02.txt +++ b/docs/tutorial02.txt @@ -5,7 +5,7 @@ Writing your first Django app, part 2 This tutorial begins where `Tutorial 1`_ left off. We're continuing the Web-poll application and will focus on Django's automatically-generated admin site. -.. _Tutorial 1: http://www.djangoproject.com/documentation/tutorial1/ +.. _Tutorial 1: ../tutorial1/ .. admonition:: Philosophy @@ -64,7 +64,7 @@ tutorial, remember?) You should see the Django admin index page: By default, you should see two types of editable content: groups and users. These are core features Django ships with by default. -.. _"I can't log in" questions: http://www.djangoproject.com/documentation/faq/#the-admin-site +.. _"I can't log in" questions: ../faq/#the-admin-site Make the poll app modifiable in the admin ========================================= @@ -402,7 +402,7 @@ Django automatically looks for a ``templates/`` subdirectory within each app package, for use as a fallback. See the `loader types documentation`_ for full information. -.. _loader types documentation: http://www.djangoproject.com/documentation/templates_python/#loader-types +.. _loader types documentation: ../templates_python/#loader-types Customize the admin index page ============================== @@ -433,5 +433,5 @@ general, see the `Django admin CSS guide`_. When you're comfortable with the admin site, read `part 3 of this tutorial`_ to start working on public poll views. -.. _Django admin CSS guide: http://www.djangoproject.com/documentation/admin_css/ -.. _part 3 of this tutorial: http://www.djangoproject.com/documentation/tutorial3/ +.. _Django admin CSS guide: ../admin_css/ +.. _part 3 of this tutorial: ../tutorial3/ diff --git a/docs/tutorial03.txt b/docs/tutorial03.txt index c4c1b4c546..17b6ec0c68 100644 --- a/docs/tutorial03.txt +++ b/docs/tutorial03.txt @@ -5,7 +5,7 @@ Writing your first Django app, part 3 This tutorial begins where `Tutorial 2`_ left off. We're continuing the Web-poll application and will focus on creating the public interface -- "views." -.. _Tutorial 2: http://www.djangoproject.com/documentation/tutorial2/ +.. _Tutorial 2: ../tutorial2/ Philosophy ========== @@ -117,8 +117,8 @@ time the URLconf module is loaded. They're super fast. .. _Wikipedia's entry: http://en.wikipedia.org/wiki/Regular_expression .. _Python documentation: http://www.python.org/doc/current/lib/module-re.html -.. _request and response documentation: http://www.djangoproject.com/documentation/request_response/ -.. _URLconf documentation: http://www.djangoproject.com/documentation/url_dispatch/ +.. _request and response documentation: ../request_response/ +.. _URLconf documentation: ../url_dispatch/ Write your first view ===================== @@ -260,8 +260,7 @@ provides a shortcut. Here's the full ``index()`` view, rewritten:: latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5] return render_to_response('polls/index.html', {'latest_poll_list': latest_poll_list}) -Note that we no longer need to import ``loader``, ``Context`` or -``HttpResponse``. +Note that once we've done this in all these views, we no longer need to import ``loader``, ``Context`` and ``HttpResponse``. The ``render_to_response()`` function takes a template name as its first argument and a dictionary as its optional second argument. It returns an @@ -300,7 +299,7 @@ rewritten:: The ``get_object_or_404()`` function takes a Django model module as its first argument and an arbitrary number of keyword arguments, which it passes to the -module's ``get_object()`` function. It raises ``Http404`` if the object doesn't +module's ``get()`` function. It raises ``Http404`` if the object doesn't exist. .. admonition:: Philosophy @@ -377,7 +376,7 @@ iterable of Choice objects and is suitable for use in the ``{% for %}`` tag. See the `template guide`_ for full details on how templates work. -.. _template guide: http://www.djangoproject.com/documentation/templates/ +.. _template guide: ../templates/ Simplifying the URLconfs ======================== @@ -464,4 +463,4 @@ All the poll app cares about is its relative URLs, not its absolute URLs. When you're comfortable with writing views, read `part 4 of this tutorial`_ to learn about simple form processing and generic views. -.. _part 4 of this tutorial: http://www.djangoproject.com/documentation/tutorial4/ +.. _part 4 of this tutorial: ../tutorial4/ diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt index 49ed649cff..7b19bdaeaf 100644 --- a/docs/tutorial04.txt +++ b/docs/tutorial04.txt @@ -120,7 +120,7 @@ Now, go to ``/polls/1/`` in your browser and vote in the poll. You should see a results page that gets updated each time you vote. If you submit the form without having chosen a choice, you should see the error message. -.. _request and response documentation: http://www.djangoproject.com/documentation/request_response/ +.. _request and response documentation: ../request_response/ Use generic views: Less code is better ====================================== @@ -226,7 +226,7 @@ Run the server, and use your new polling app based on generic views. For full details on generic views, see the `generic views documentation`_. -.. _generic views documentation: http://www.djangoproject.com/documentation/generic_views/ +.. _generic views documentation: ../generic_views/ Coming soon =========== @@ -241,4 +241,4 @@ installments: * Advanced admin features: Permissions * Advanced admin features: Custom JavaScript -.. _Tutorial 3: http://www.djangoproject.com/documentation/tutorial3/ +.. _Tutorial 3: ../tutorial3/ diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt index 00a7af027a..da4be2c746 100644 --- a/docs/url_dispatch.txt +++ b/docs/url_dispatch.txt @@ -45,8 +45,8 @@ algorithm the system follows to determine which Python code to execute: `request object`_ as its first argument and any values captured in the regex as remaining arguments. -.. _settings file: http://www.djangoproject.com/documentation/settings/ -.. _request object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects +.. _settings file: ../settings/ +.. _request object: ../request_response/#httprequest-objects Example ======= @@ -286,7 +286,7 @@ With this in mind, the above example can be written more concisely as:: Note that you don't put a trailing dot (``"."``) in the prefix. Django puts that in automatically. -.. _Django overview: http://www.djangoproject.com/documentation/overview/ +.. _Django overview: ../overview/ Multiple view prefixes ---------------------- @@ -387,13 +387,13 @@ In this example, for a request to ``/blog/2005/``, Django will call the This technique is used in `generic views`_ and in the `syndication framework`_ to pass metadata and options to views. -.. _generic views: http://www.djangoproject.com/documentation/generic_views/ -.. _syndication framework: http://www.djangoproject.com/documentation/syndication/ +.. _generic views: ../generic_views/ +.. _syndication framework: ../syndication/ Passing extra options to ``include()`` -------------------------------------- -**New in the Django development version.** +**New in Django development version.** Similarly, you can pass extra options to ``include()``. When you pass extra options to ``include()``, *each* line in the included URLconf will be passed @@ -435,7 +435,7 @@ every view in the the included URLconf accepts the extra options you're passing. Passing callable objects instead of strings =========================================== -**New in the Django development version.** +**New in Django development version.** Some developers find it more natural to pass the actual Python function object rather than a string containing the path to its module. This alternative is |