Removed 'Only in Django development version' messages from the docs, because frozen docs for version 0.90 are now available
git-svn-id: http://code.djangoproject.com/svn/django/trunk@1898 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
7573756e18
commit
786e5477b7
|
@ -170,8 +170,8 @@ Change a password with ``set_password()``::
|
||||||
Passwords
|
Passwords
|
||||||
---------
|
---------
|
||||||
|
|
||||||
**This only applies to the Django development version.** Previous versions,
|
Previous versions, such as Django 0.90, used simple MD5 hashes without password
|
||||||
such as Django 0.90, used simple MD5 hashes without password salts.
|
salts.
|
||||||
|
|
||||||
The ``password`` field of a ``User`` object is a string in this format::
|
The ``password`` field of a ``User`` object is a string in this format::
|
||||||
|
|
||||||
|
@ -314,9 +314,8 @@ Here's the same thing, using Python 2.4's decorator syntax::
|
||||||
Note that ``user_passes_test`` does not automatically check that the ``User``
|
Note that ``user_passes_test`` does not automatically check that the ``User``
|
||||||
is not anonymous.
|
is not anonymous.
|
||||||
|
|
||||||
**New in the Django development version**: ``user_passes_test()`` takes an
|
``user_passes_test()`` takes an optional ``login_url`` argument, which lets you
|
||||||
optional ``login_url`` argument, which lets you specify the URL for your login
|
specify the URL for your login page (``/accounts/login/`` by default).
|
||||||
page (``/accounts/login/`` by default).
|
|
||||||
|
|
||||||
Example in Python 2.3 syntax::
|
Example in Python 2.3 syntax::
|
||||||
|
|
||||||
|
|
|
@ -48,8 +48,7 @@ Examples:
|
||||||
locmem:/// A more sophisticated local memory cache;
|
locmem:/// A more sophisticated local memory cache;
|
||||||
this is multi-process- and thread-safe.
|
this is multi-process- and thread-safe.
|
||||||
|
|
||||||
dummy:/// **New in Django development version.**
|
dummy:/// Doesn't actually cache; just implements the
|
||||||
Doesn't actually cache; just implements the
|
|
||||||
cache backend interface and doesn't do
|
cache backend interface and doesn't do
|
||||||
anything. This is an easy way to turn off
|
anything. This is an easy way to turn off
|
||||||
caching for a test environment.
|
caching for a test environment.
|
||||||
|
|
|
@ -222,8 +222,6 @@ If you pass an invalid keyword argument, the function will raise ``TypeError``.
|
||||||
OR lookups
|
OR lookups
|
||||||
----------
|
----------
|
||||||
|
|
||||||
**New in Django development version.**
|
|
||||||
|
|
||||||
By default, multiple lookups are "AND"ed together. If you'd like to use ``OR``
|
By default, multiple lookups are "AND"ed together. If you'd like to use ``OR``
|
||||||
statements in your queries, use the ``complex`` lookup type.
|
statements in your queries, use the ``complex`` lookup type.
|
||||||
|
|
||||||
|
|
|
@ -54,9 +54,8 @@ createsuperuser
|
||||||
Creates a superuser account interactively. It asks you for a username, e-mail
|
Creates a superuser account interactively. It asks you for a username, e-mail
|
||||||
address and password.
|
address and password.
|
||||||
|
|
||||||
**New in Django development version:** You can specify
|
You can specify ``username email password`` on the command line, for convenient
|
||||||
``username email password`` on the command line, for convenient use in shell
|
use in shell scripts. Example::
|
||||||
scripts. Example::
|
|
||||||
|
|
||||||
django-admin.py createsuperuser john john@example.com mypassword
|
django-admin.py createsuperuser john john@example.com mypassword
|
||||||
|
|
||||||
|
|
|
@ -118,8 +118,6 @@ receiving a separate e-mail::
|
||||||
Preventing header injection
|
Preventing header injection
|
||||||
===========================
|
===========================
|
||||||
|
|
||||||
**New in Django development version.**
|
|
||||||
|
|
||||||
`Header injection`_ is a security exploit in which an attacker inserts extra
|
`Header injection`_ is a security exploit in which an attacker inserts extra
|
||||||
e-mail headers to control the "To:" and "From:" in e-mail messages that your
|
e-mail headers to control the "To:" and "From:" in e-mail messages that your
|
||||||
scripts generate.
|
scripts generate.
|
||||||
|
|
|
@ -129,9 +129,9 @@ arguments:
|
||||||
``extra_context`` A dictionary of extra data to put into the
|
``extra_context`` A dictionary of extra data to put into the
|
||||||
template's context.
|
template's context.
|
||||||
|
|
||||||
``processors`` **New in Django development version.** A tuple of
|
``processors`` A tuple of processors to apply to the
|
||||||
processors to apply to the ``DjangoContext`` of
|
``DjangoContext`` of this view's template. See the
|
||||||
this view's template. See the `DjangoContext docs`_
|
`DjangoContext docs`_
|
||||||
======================= ==================================================
|
======================= ==================================================
|
||||||
|
|
||||||
.. _database API docs: http://www.djangoproject.com/documentation/db_api/
|
.. _database API docs: http://www.djangoproject.com/documentation/db_api/
|
||||||
|
@ -150,8 +150,7 @@ The date-based generic functions are:
|
||||||
``num_latest`` The number of items to display on the page.
|
``num_latest`` The number of items to display on the page.
|
||||||
Defaults to 15.
|
Defaults to 15.
|
||||||
|
|
||||||
``allow_empty`` **New in Django development version.**
|
``allow_empty`` If ``False`` and there are no objects to display,
|
||||||
If ``False`` and there are no objects to display,
|
|
||||||
the view will raise a 404 instead of displaying
|
the view will raise a 404 instead of displaying
|
||||||
an empty index page. ``False`` is default.
|
an empty index page. ``False`` is default.
|
||||||
======================= =================================================
|
======================= =================================================
|
||||||
|
|
|
@ -151,9 +151,8 @@ subclass of dictionary. Exceptions are outlined here:
|
||||||
other dictionary functions that have side effects, can only be called on
|
other dictionary functions that have side effects, can only be called on
|
||||||
a mutable ``QueryDict`` (one that was created via ``copy()``).
|
a mutable ``QueryDict`` (one that was created via ``copy()``).
|
||||||
|
|
||||||
* ``__contains__(key)`` -- **New in Django development version.** Returns
|
* ``__contains__(key)`` -- Returns ``True`` if the given key is set. This
|
||||||
``True`` if the given key is set. This lets you do, e.g.,
|
lets you do, e.g., ``if "foo" in request.GET``.
|
||||||
``if "foo" in request.GET``.
|
|
||||||
|
|
||||||
* ``get(key, default)`` -- Uses the same logic as ``__getitem__()`` above,
|
* ``get(key, default)`` -- Uses the same logic as ``__getitem__()`` above,
|
||||||
with a hook for returning a default value if the key doesn't exist.
|
with a hook for returning a default value if the key doesn't exist.
|
||||||
|
@ -361,8 +360,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
||||||
an HTTP status code 302.
|
an HTTP status code 302.
|
||||||
|
|
||||||
``HttpResponsePermanentRedirect``
|
``HttpResponsePermanentRedirect``
|
||||||
**New in Django development version.***
|
|
||||||
|
|
||||||
Like ``HttpResponseRedirect``, but it returns a permanent redirect (HTTP
|
Like ``HttpResponseRedirect``, but it returns a permanent redirect (HTTP
|
||||||
status code 301) instead of a "found" redirect (status code 302).
|
status code 301) instead of a "found" redirect (status code 302).
|
||||||
|
|
||||||
|
|
|
@ -35,7 +35,7 @@ it and write to it.
|
||||||
It implements the following standard dictionary methods:
|
It implements the following standard dictionary methods:
|
||||||
|
|
||||||
* ``__contains__(key)``
|
* ``__contains__(key)``
|
||||||
**New in Django development version.** Example: ``'fav_color' in request.session``
|
Example: ``'fav_color' in request.session``
|
||||||
|
|
||||||
* ``__getitem__(key)``
|
* ``__getitem__(key)``
|
||||||
Example: ``fav_color = request.session['fav_color']``
|
Example: ``fav_color = request.session['fav_color']``
|
||||||
|
@ -182,10 +182,9 @@ deleted::
|
||||||
# request.session['foo'] instead of request.session.
|
# request.session['foo'] instead of request.session.
|
||||||
request.session['foo']['bar'] = 'baz'
|
request.session['foo']['bar'] = 'baz'
|
||||||
|
|
||||||
**Only available in Django development version.** To change this default
|
To change this default behavior, set the ``SESSION_SAVE_EVERY_REQUEST`` setting
|
||||||
behavior, set the ``SESSION_SAVE_EVERY_REQUEST`` setting to ``True``. If
|
to ``True``. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, Django will save
|
||||||
``SESSION_SAVE_EVERY_REQUEST`` is ``True``, Django will save the session to the
|
the session to the database on every single request.
|
||||||
database on every single request.
|
|
||||||
|
|
||||||
Note that the session cookie is only sent when a session has been created or
|
Note that the session cookie is only sent when a session has been created or
|
||||||
modified. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, the session cookie
|
modified. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, the session cookie
|
||||||
|
@ -218,8 +217,7 @@ domain cookie.
|
||||||
SESSION_COOKIE_NAME
|
SESSION_COOKIE_NAME
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
Default: ``'sessionid'`` (**Django development version.** Previous default was
|
Default: ``'sessionid'``
|
||||||
``'hotclub'``, which was deemed too pornish.)
|
|
||||||
|
|
||||||
The name of the cookie to use for sessions. This can be whatever you want.
|
The name of the cookie to use for sessions. This can be whatever you want.
|
||||||
|
|
||||||
|
@ -228,8 +226,6 @@ SESSION_SAVE_EVERY_REQUEST
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
**Only available in Django development version.**
|
|
||||||
|
|
||||||
Whether to save the session data on every request. If this is ``False``
|
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 --
|
(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.
|
that is, if any of its dictionary values have been assigned or deleted.
|
||||||
|
|
|
@ -525,8 +525,7 @@ domain cookie. See the `session docs`_.
|
||||||
SESSION_COOKIE_NAME
|
SESSION_COOKIE_NAME
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
Default: ``'sessionid'`` (**Django development version.** Previous default was
|
Default: ``'sessionid'``
|
||||||
``'hotclub'``, which was deemed too pornish.)
|
|
||||||
|
|
||||||
The name of the cookie to use for sessions. This can be whatever you want.
|
The name of the cookie to use for sessions. This can be whatever you want.
|
||||||
See the `session docs`_.
|
See the `session docs`_.
|
||||||
|
@ -556,8 +555,6 @@ Default::
|
||||||
"django.core.context_processors.debug",
|
"django.core.context_processors.debug",
|
||||||
"django.core.context_processors.i18n")
|
"django.core.context_processors.i18n")
|
||||||
|
|
||||||
**Only available in Django development version.**
|
|
||||||
|
|
||||||
A tuple of callables that are used to populate the context in ``DjangoContext``.
|
A tuple of callables that are used to populate the context in ``DjangoContext``.
|
||||||
These callables take a request object as their argument and return a dictionary
|
These callables take a request object as their argument and return a dictionary
|
||||||
of items to be merged into the context.
|
of items to be merged into the context.
|
||||||
|
@ -567,8 +564,6 @@ TEMPLATE_DEBUG
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
**Only available in Django development version.**
|
|
||||||
|
|
||||||
A boolean that turns on/off template debug mode. If this is ``True``, the fancy
|
A boolean that turns on/off template debug mode. If this is ``True``, the fancy
|
||||||
error page will display a detailed report for any ``TemplateSyntaxError``. This
|
error page will display a detailed report for any ``TemplateSyntaxError``. This
|
||||||
report contains the relevant snippet of the template, with the appropriate line
|
report contains the relevant snippet of the template, with the appropriate line
|
||||||
|
|
|
@ -278,8 +278,8 @@ In the above, the ``load`` tag loads the ``comments`` tag library, which then
|
||||||
makes the ``comment_form`` tag available for use. Consult the documentation
|
makes the ``comment_form`` tag available for use. Consult the documentation
|
||||||
area in your admin to find the list of custom libraries in your installation.
|
area in your admin to find the list of custom libraries in your installation.
|
||||||
|
|
||||||
**New in Django development version:** The ``{% load %}`` tag can take multiple
|
The ``{% load %}`` tag can take multiple library names, separated by spaces.
|
||||||
library names, separated by spaces. Example::
|
Example::
|
||||||
|
|
||||||
{% load comments i18n %}
|
{% load comments i18n %}
|
||||||
|
|
||||||
|
@ -500,8 +500,6 @@ Just like ``ifequal``, except it tests that the two arguments are not equal.
|
||||||
include
|
include
|
||||||
~~~~~~~
|
~~~~~~~
|
||||||
|
|
||||||
**Only available in Django development version.**
|
|
||||||
|
|
||||||
Loads a template and renders it with the current context. This is a way of
|
Loads a template and renders it with the current context. This is a way of
|
||||||
"including" other templates within a template.
|
"including" other templates within a template.
|
||||||
|
|
||||||
|
|
|
@ -276,11 +276,6 @@ optional, third positional argument, ``processors``. In this example, the
|
||||||
'foo': 'bar',
|
'foo': 'bar',
|
||||||
}, [ip_address_processor])
|
}, [ip_address_processor])
|
||||||
|
|
||||||
Note: The concept of template-context processors is new in the Django
|
|
||||||
development version. In Django 0.90, ``DjangoContext`` automatically populates
|
|
||||||
the context with all of the values explained below, but it's not possible to
|
|
||||||
add and remove processors.
|
|
||||||
|
|
||||||
Here's what each of the default processors does:
|
Here's what each of the default processors does:
|
||||||
|
|
||||||
.. _HttpRequest object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects
|
.. _HttpRequest object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects
|
||||||
|
@ -534,8 +529,6 @@ filters are registered. So, near the top of your module, put the following::
|
||||||
Writing custom template filters
|
Writing custom template filters
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
**This section applies to the Django development version.**
|
|
||||||
|
|
||||||
Custom filters are just Python functions that take one or two arguments:
|
Custom filters are just Python functions that take one or two arguments:
|
||||||
|
|
||||||
* The value of the variable (input) -- not necessarily a string.
|
* The value of the variable (input) -- not necessarily a string.
|
||||||
|
@ -595,8 +588,6 @@ will use the function's name as the filter name.
|
||||||
Writing custom template tags
|
Writing custom template tags
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
**This section applies to the Django development version.**
|
|
||||||
|
|
||||||
Tags are more complex than filters, because tags can do anything.
|
Tags are more complex than filters, because tags can do anything.
|
||||||
|
|
||||||
A quick overview
|
A quick overview
|
||||||
|
|
|
@ -51,9 +51,6 @@ algorithm the system follows to determine which Python code to execute:
|
||||||
Example
|
Example
|
||||||
=======
|
=======
|
||||||
|
|
||||||
**This syntax is new in the Django development version.** See "Named groups"
|
|
||||||
below if you're using Django 0.90.
|
|
||||||
|
|
||||||
Here's a sample URLconf::
|
Here's a sample URLconf::
|
||||||
|
|
||||||
from django.conf.urls.defaults import *
|
from django.conf.urls.defaults import *
|
||||||
|
@ -110,9 +107,6 @@ to a view. In more advanced usage, it's possible to use *named*
|
||||||
regular-expression groups to capture URL bits and pass them as *keyword*
|
regular-expression groups to capture URL bits and pass them as *keyword*
|
||||||
arguments to a view.
|
arguments to a view.
|
||||||
|
|
||||||
(Note that support for non-named regex groups is a new feature in the Django
|
|
||||||
development version. Django 0.90 requires named groups.)
|
|
||||||
|
|
||||||
In Python regular expressions, the syntax for named regular-expression groups
|
In Python regular expressions, the syntax for named regular-expression groups
|
||||||
is ``(?P<name>pattern)``, where ``name`` is the name of the group and
|
is ``(?P<name>pattern)``, where ``name`` is the name of the group and
|
||||||
``pattern`` is some pattern to match.
|
``pattern`` is some pattern to match.
|
||||||
|
|
Loading…
Reference in New Issue