Fixed broken links, round 4. refs #19516
This commit is contained in:
Tim Graham
parent
13a2b11425
commit
067505ad19
|
|
@ -27,6 +27,8 @@ use of the ``REMOTE_USER`` value using the ``RemoteUserMiddleware`` and
|
|||
Configuration
|
||||
=============
|
||||
|
||||
.. class:: django.contrib.auth.middleware.RemoteUserMiddleware
|
||||
|
||||
First, you must add the
|
||||
:class:`django.contrib.auth.middleware.RemoteUserMiddleware` to the
|
||||
:setting:`MIDDLEWARE_CLASSES` setting **after** the
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
Writing custom django-admin commands
|
||||
====================================
|
||||
|
||||
.. module:: django.core.management
|
||||
|
||||
Applications can register their own actions with ``manage.py``. For example,
|
||||
you might want to add a ``manage.py`` action for a Django app that you're
|
||||
distributing. In this document, we will be building a custom ``closepoll``
|
||||
|
|
@ -261,6 +263,13 @@ the :meth:`~BaseCommand.handle` method must be implemented.
|
|||
|
||||
The actual logic of the command. Subclasses must implement this method.
|
||||
|
||||
.. method:: BaseCommand.validate(app=None, display_num_errors=False)
|
||||
|
||||
Validates the given app, raising :class:`CommandError` for any errors.
|
||||
|
||||
If ``app`` is None, then all installed apps are validated.
|
||||
|
||||
|
||||
.. _ref-basecommand-subclasses:
|
||||
|
||||
BaseCommand subclasses
|
||||
|
|
|
|||
|
|
@ -153,8 +153,8 @@ class, from which everything is descended.
|
|||
|
||||
Initializing your new field is a matter of separating out any arguments that are
|
||||
specific to your case from the common arguments and passing the latter to the
|
||||
:meth:`~django.db.models.Field.__init__` method of
|
||||
:class:`~django.db.models.Field` (or your parent class).
|
||||
``__init__()`` method of :class:`~django.db.models.Field` (or your parent
|
||||
class).
|
||||
|
||||
In our example, we'll call our field ``HandField``. (It's a good idea to call
|
||||
your :class:`~django.db.models.Field` subclass ``<Something>Field``, so it's
|
||||
|
|
@ -602,11 +602,11 @@ Returns the default form field to use when this field is displayed in a model.
|
|||
This method is called by the :class:`~django.forms.ModelForm` helper.
|
||||
|
||||
All of the ``kwargs`` dictionary is passed directly to the form field's
|
||||
:meth:`~django.forms.Field__init__` method. Normally, all you need to do is
|
||||
set up a good default for the ``form_class`` argument and then delegate further
|
||||
handling to the parent class. This might require you to write a custom form
|
||||
field (and even a form widget). See the :doc:`forms documentation
|
||||
</topics/forms/index>` for information about this, and take a look at the code in
|
||||
``__init__()`` method. Normally, all you need to do is set up a good default
|
||||
for the ``form_class`` argument and then delegate further handling to the
|
||||
parent class. This might require you to write a custom form field (and even a
|
||||
form widget). See the :doc:`forms documentation </topics/forms/index>` for
|
||||
information about this, and take a look at the code in
|
||||
:mod:`django.contrib.localflavor` for some examples of custom widgets.
|
||||
|
||||
Continuing our ongoing example, we can write the :meth:`.formfield` method as::
|
||||
|
|
@ -668,7 +668,7 @@ Converting field data for serialization
|
|||
.. method:: Field.value_to_string(self, obj)
|
||||
|
||||
This method is used by the serializers to convert the field into a string for
|
||||
output. Calling :meth:`Field._get_val_from_obj(obj)` is the best way to get the
|
||||
output. Calling ``Field._get_val_from_obj(obj)`` is the best way to get the
|
||||
value to serialize. For example, since our ``HandField`` uses strings for its
|
||||
data storage anyway, we can reuse some existing conversion code::
|
||||
|
||||
|
|
@ -692,12 +692,12 @@ smoothly:
|
|||
a field that's similar to what you want and extend it a little bit,
|
||||
instead of creating an entirely new field from scratch.
|
||||
|
||||
2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
|
||||
2. Put a ``__str__()`` or ``__unicode__()`` method on the class you're
|
||||
wrapping up as a field. There are a lot of places where the default
|
||||
behavior of the field code is to call
|
||||
:func:`~django.utils.encoding.force_text` on the value. (In our
|
||||
examples in this document, ``value`` would be a ``Hand`` instance, not a
|
||||
``HandField``). So if your :meth:`__unicode__` method automatically
|
||||
``HandField``). So if your ``__unicode__()`` method automatically
|
||||
converts to the string form of your Python object, you can save yourself
|
||||
a lot of work.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ these changes.
|
|||
* The old imports for CSRF functionality (``django.contrib.csrf.*``),
|
||||
which moved to core in 1.2, will be removed.
|
||||
|
||||
* The :mod:`django.contrib.gis.db.backend` module will be removed in favor
|
||||
* The ``django.contrib.gis.db.backend`` module will be removed in favor
|
||||
of the specific backends.
|
||||
|
||||
* ``SMTPConnection`` will be removed in favor of a generic Email backend API.
|
||||
|
|
@ -122,23 +122,23 @@ these changes.
|
|||
The :attr:`~django.test.client.Response.templates` attribute should be
|
||||
used instead.
|
||||
|
||||
* The :class:`~django.test.simple.DjangoTestRunner` will be removed.
|
||||
* The ``django.test.simple.DjangoTestRunner`` will be removed.
|
||||
Instead use a unittest-native class. The features of the
|
||||
:class:`django.test.simple.DjangoTestRunner` (including fail-fast and
|
||||
``django.test.simple.DjangoTestRunner`` (including fail-fast and
|
||||
Ctrl-C test termination) can currently be provided by the unittest-native
|
||||
:class:`TextTestRunner`.
|
||||
:class:`~unittest.TextTestRunner`.
|
||||
|
||||
* The undocumented function
|
||||
:func:`django.contrib.formtools.utils.security_hash` will be removed,
|
||||
instead use :func:`django.contrib.formtools.utils.form_hmac`
|
||||
``django.contrib.formtools.utils.security_hash`` will be removed,
|
||||
instead use ``django.contrib.formtools.utils.form_hmac``
|
||||
|
||||
* The function-based generic view modules will be removed in favor of their
|
||||
class-based equivalents, outlined :doc:`here
|
||||
</topics/class-based-views/index>`.
|
||||
|
||||
* The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be
|
||||
* The ``django.core.servers.basehttp.AdminMediaHandler`` will be
|
||||
removed. In its place use
|
||||
:class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
|
||||
``django.contrib.staticfiles.handlers.StaticFilesHandler``.
|
||||
|
||||
* The template tags library ``adminmedia`` and the template tag ``{%
|
||||
admin_media_prefix %}`` will be removed in favor of the generic static files
|
||||
|
|
@ -150,8 +150,7 @@ these changes.
|
|||
an implied string. In 1.4, this behavior is provided by a version of the tag
|
||||
in the ``future`` template tag library.
|
||||
|
||||
* The :djadmin:`reset` and :djadmin:`sqlreset` management commands
|
||||
will be removed.
|
||||
* The ``reset`` and ``sqlreset`` management commands will be removed.
|
||||
|
||||
* Authentication backends will need to support an inactive user
|
||||
being passed to all methods dealing with permissions.
|
||||
|
|
@ -162,11 +161,11 @@ these changes.
|
|||
a :class:`~django.contrib.gis.geos.GEOSException` when called
|
||||
on a geometry with no SRID value.
|
||||
|
||||
* :class:`~django.http.CompatCookie` will be removed in favor of
|
||||
:class:`~django.http.SimpleCookie`.
|
||||
* ``django.http.CompatCookie`` will be removed in favor of
|
||||
``django.http.SimpleCookie``.
|
||||
|
||||
* :class:`django.core.context_processors.PermWrapper` and
|
||||
:class:`django.core.context_processors.PermLookupDict` will be removed in
|
||||
* ``django.core.context_processors.PermWrapper`` and
|
||||
``django.core.context_processors.PermLookupDict`` will be removed in
|
||||
favor of the corresponding
|
||||
:class:`django.contrib.auth.context_processors.PermWrapper` and
|
||||
:class:`django.contrib.auth.context_processors.PermLookupDict`,
|
||||
|
|
@ -213,8 +212,7 @@ these changes.
|
|||
``django.utils.itercompat.all`` and ``django.utils.itercompat.any`` will
|
||||
be removed. The Python builtin versions should be used instead.
|
||||
|
||||
* The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
|
||||
:func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
|
||||
* The ``csrf_response_exempt`` and ``csrf_view_exempt`` decorators will
|
||||
be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
|
||||
returns the same function), and ``csrf_view_exempt`` has been a
|
||||
synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
|
||||
|
|
|
|||
|
|
@ -349,7 +349,7 @@ Login and logout signals
|
|||
The auth framework uses two :doc:`signals </topics/signals>` that can be used
|
||||
for notification when a user logs in or out.
|
||||
|
||||
.. function:: django.contrib.auth.signals.user_logged_in
|
||||
.. function:: user_logged_in
|
||||
|
||||
Sent when a user logs in successfully.
|
||||
|
||||
|
|
@ -364,7 +364,7 @@ for notification when a user logs in or out.
|
|||
``user``
|
||||
The user instance that just logged in.
|
||||
|
||||
.. function:: django.contrib.auth.signals.user_logged_out
|
||||
.. function:: user_logged_out
|
||||
|
||||
Sent when the logout method is called.
|
||||
|
||||
|
|
@ -379,9 +379,9 @@ for notification when a user logs in or out.
|
|||
The user instance that just logged out or ``None`` if the
|
||||
user was not authenticated.
|
||||
|
||||
.. function:: django.contrib.auth.signals.user_login_failed
|
||||
.. function:: user_login_failed
|
||||
|
||||
.. versionadded:: 1.5
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Sent when the user failed to login successfully
|
||||
|
||||
|
|
|
|||
|
|
@ -140,6 +140,8 @@ with the rest of :ref:`Django's unit tests <running-unit-tests>`.
|
|||
Run only GeoDjango tests
|
||||
------------------------
|
||||
|
||||
.. class:: django.contrib.gis.tests.GeoDjangoTestSuiteRunner
|
||||
|
||||
To run *only* the tests for GeoDjango, the :setting:`TEST_RUNNER`
|
||||
setting must be changed to use the
|
||||
:class:`~django.contrib.gis.tests.GeoDjangoTestSuiteRunner`::
|
||||
|
|
|
|||
|
|
@ -149,6 +149,8 @@ tags for the levels you wish to override::
|
|||
Using messages in views and templates
|
||||
=====================================
|
||||
|
||||
.. function:: add_message(request, level, message, extra_tags='', fail_silently=False)
|
||||
|
||||
Adding a message
|
||||
----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -27,9 +27,8 @@ module system.
|
|||
.. warning::
|
||||
|
||||
Many of these signals are sent by various model methods like
|
||||
:meth:`~django.db.models.Model.__init__` or
|
||||
:meth:`~django.db.models.Model.save` that you can overwrite in your own
|
||||
code.
|
||||
``__init__()`` or :meth:`~django.db.models.Model.save` that you can
|
||||
override in your own code.
|
||||
|
||||
If you override these methods on your model, you must call the parent class'
|
||||
methods for this signals to be sent.
|
||||
|
|
@ -47,7 +46,7 @@ pre_init
|
|||
.. ^^^^^^^ this :module: hack keeps Sphinx from prepending the module.
|
||||
|
||||
Whenever you instantiate a Django model, this signal is sent at the beginning
|
||||
of the model's :meth:`~django.db.models.Model.__init__` method.
|
||||
of the model's ``__init__()`` method.
|
||||
|
||||
Arguments sent with this signal:
|
||||
|
||||
|
|
@ -55,12 +54,10 @@ Arguments sent with this signal:
|
|||
The model class that just had an instance created.
|
||||
|
||||
``args``
|
||||
A list of positional arguments passed to
|
||||
:meth:`~django.db.models.Model.__init__`:
|
||||
A list of positional arguments passed to ``__init__()``:
|
||||
|
||||
``kwargs``
|
||||
A dictionary of keyword arguments passed to
|
||||
:meth:`~django.db.models.Model.__init__`:.
|
||||
A dictionary of keyword arguments passed to ``__init__()``:
|
||||
|
||||
For example, the :doc:`tutorial </intro/tutorial01>` has this line::
|
||||
|
||||
|
|
@ -74,7 +71,7 @@ Argument Value
|
|||
``sender`` ``Poll`` (the class itself)
|
||||
|
||||
``args`` ``[]`` (an empty list because there were no positional
|
||||
arguments passed to ``__init__``.)
|
||||
arguments passed to ``__init__()``.)
|
||||
|
||||
``kwargs`` ``{'question': "What's up?", 'pub_date': datetime.now()}``
|
||||
========== ===============================================================
|
||||
|
|
@ -85,7 +82,7 @@ post_init
|
|||
.. data:: django.db.models.signals.post_init
|
||||
:module:
|
||||
|
||||
Like pre_init, but this one is sent when the :meth:`~django.db.models.Model.__init__`: method finishes.
|
||||
Like pre_init, but this one is sent when the ``__init__()`` method finishes.
|
||||
|
||||
Arguments sent with this signal:
|
||||
|
||||
|
|
|
|||
|
|
@ -277,8 +277,9 @@ Handle uploaded files using the new API
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Replace use of uploaded files -- that is, entries in ``request.FILES`` -- as
|
||||
simple dictionaries with the new :class:`~django.core.files.UploadedFile`. The
|
||||
old dictionary syntax no longer works.
|
||||
simple dictionaries with the new
|
||||
:class:`~django.core.files.uploadedfile.UploadedFile`. The old dictionary
|
||||
syntax no longer works.
|
||||
|
||||
Thus, in a view like::
|
||||
|
||||
|
|
@ -410,7 +411,7 @@ U.S. local flavor
|
|||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
``django.contrib.localflavor.usa`` has been renamed to
|
||||
:mod:`django.contrib.localflavor.us`. This change was made to match the naming
|
||||
``django.contrib.localflavor.us``. This change was made to match the naming
|
||||
scheme of other local flavors. To migrate your code, all you need to do is
|
||||
change the imports.
|
||||
|
||||
|
|
@ -642,8 +643,8 @@ The generic relation classes -- ``GenericForeignKey`` and ``GenericRelation``
|
|||
Testing
|
||||
-------
|
||||
|
||||
:meth:`django.test.Client.login` has changed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
:meth:`django.test.client.Client.login` has changed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Old (0.96)::
|
||||
|
||||
|
|
@ -721,7 +722,7 @@ To update your code:
|
|||
1. Use :class:`django.utils.datastructures.SortedDict` wherever you were
|
||||
using ``django.newforms.forms.SortedDictFromList``.
|
||||
|
||||
2. Because :meth:`django.utils.datastructures.SortedDict.copy` doesn't
|
||||
2. Because ``django.utils.datastructures.SortedDict.copy`` doesn't
|
||||
return a deepcopy as ``SortedDictFromList.copy()`` did, you will need
|
||||
to update your code if you were relying on a deepcopy. Do this by using
|
||||
``copy.deepcopy`` directly.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ A number of features have been added to Django's model layer:
|
|||
You can now control whether or not Django creates database tables for a model
|
||||
using the :attr:`~Options.managed` model option. This defaults to ``True``,
|
||||
meaning that Django will create the appropriate database tables in
|
||||
:djadmin:`syncdb` and remove them as part of :djadmin:`reset` command. That
|
||||
:djadmin:`syncdb` and remove them as part of ``reset`` command. That
|
||||
is, Django *manages* the database table's lifecycle.
|
||||
|
||||
If you set this to ``False``, however, no database table creating or deletion
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ If you are using a 32-bit platform, you're off the hook; you'll observe no
|
|||
differences as a result of this change.
|
||||
|
||||
However, **users on 64-bit platforms may experience some problems** using the
|
||||
:djadmin:`reset` management command. Prior to this change, 64-bit platforms
|
||||
``reset`` management command. Prior to this change, 64-bit platforms
|
||||
would generate a 64-bit, 16 character digest in the constraint name; for
|
||||
example::
|
||||
|
||||
|
|
@ -48,14 +48,14 @@ Following this change, all platforms, regardless of word size, will generate a
|
|||
|
||||
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
|
||||
|
||||
As a result of this change, you will not be able to use the :djadmin:`reset`
|
||||
As a result of this change, you will not be able to use the ``reset``
|
||||
management command on any table made by a 64-bit machine. This is because the
|
||||
the new generated name will not match the historically generated name; as a
|
||||
result, the SQL constructed by the reset command will be invalid.
|
||||
|
||||
If you need to reset an application that was created with 64-bit constraints,
|
||||
you will need to manually drop the old constraint prior to invoking
|
||||
:djadmin:`reset`.
|
||||
``reset``.
|
||||
|
||||
Test cases are now run in a transaction
|
||||
---------------------------------------
|
||||
|
|
@ -120,9 +120,8 @@ has been saved.
|
|||
Changes to how model formsets are saved
|
||||
---------------------------------------
|
||||
|
||||
.. currentmodule:: django.forms.models
|
||||
|
||||
In Django 1.1, :class:`BaseModelFormSet` now calls :meth:`ModelForm.save()`.
|
||||
In Django 1.1, :class:`~django.forms.models.BaseModelFormSet` now calls
|
||||
``ModelForm.save()``.
|
||||
|
||||
This is backwards-incompatible if you were modifying ``self.initial`` in a model
|
||||
formset's ``__init__``, or if you relied on the internal ``_total_form_count``
|
||||
|
|
@ -146,7 +145,7 @@ Permanent redirects and the ``redirect_to()`` generic view
|
|||
----------------------------------------------------------
|
||||
|
||||
Django 1.1 adds a ``permanent`` argument to the
|
||||
:func:`django.views.generic.simple.redirect_to()` view. This is technically
|
||||
``django.views.generic.simple.redirect_to()`` view. This is technically
|
||||
backwards-incompatible if you were using the ``redirect_to`` view with a
|
||||
format-string key called 'permanent', which is highly unlikely.
|
||||
|
||||
|
|
@ -211,8 +210,8 @@ Query expressions
|
|||
|
||||
Queries can now refer to a another field on the query and can traverse
|
||||
relationships to refer to fields on related models. This is implemented in the
|
||||
new :class:`F` object; for full details, including examples, consult the
|
||||
:ref:`documentation for F expressions <query-expressions>`.
|
||||
new :class:`~django.db.models.F` object; for full details, including examples,
|
||||
consult the :ref:`documentation for F expressions <query-expressions>`.
|
||||
|
||||
Model improvements
|
||||
------------------
|
||||
|
|
@ -225,7 +224,7 @@ A number of features have been added to Django's model layer:
|
|||
You can now control whether or not Django manages the life-cycle of the database
|
||||
tables for a model using the :attr:`~Options.managed` model option. This
|
||||
defaults to ``True``, meaning that Django will create the appropriate database
|
||||
tables in :djadmin:`syncdb` and remove them as part of the :djadmin:`reset`
|
||||
tables in :djadmin:`syncdb` and remove them as part of the ``reset``
|
||||
command. That is, Django *manages* the database table's lifecycle.
|
||||
|
||||
If you set this to ``False``, however, no database table creating or deletion
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ GeoDjango
|
|||
=========
|
||||
|
||||
The function-based :setting:`TEST_RUNNER` previously used to execute
|
||||
the GeoDjango test suite, :func:`django.contrib.gis.tests.run_gis_tests`,
|
||||
the GeoDjango test suite, ``django.contrib.gis.tests.run_gis_tests``,
|
||||
was finally deprecated in favor of a class-based test runner,
|
||||
:class:`django.contrib.gis.tests.GeoDjangoTestSuiteRunner`, added in this
|
||||
release.
|
||||
|
|
|
|||
|
|
@ -311,37 +311,35 @@ As a result of the introduction of class-based generic views, the
|
|||
function-based generic views provided by Django have been deprecated.
|
||||
The following modules and the views they contain have been deprecated:
|
||||
|
||||
* :mod:`django.views.generic.create_update`
|
||||
* :mod:`django.views.generic.date_based`
|
||||
* :mod:`django.views.generic.list_detail`
|
||||
* :mod:`django.views.generic.simple`
|
||||
* ``django.views.generic.create_update``
|
||||
* ``django.views.generic.date_based``
|
||||
* ``django.views.generic.list_detail``
|
||||
* ``django.views.generic.simple``
|
||||
|
||||
Test client response ``template`` attribute
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Django's :ref:`test client <test-client>` returns
|
||||
:class:`~django.test.client.Response` objects annotated with extra testing
|
||||
information. In Django versions prior to 1.3, this included a
|
||||
:attr:`~django.test.client.Response.template` attribute containing information
|
||||
about templates rendered in generating the response: either None, a single
|
||||
:class:`~django.template.Template` object, or a list of
|
||||
:class:`~django.template.Template` objects. This inconsistency in return values
|
||||
(sometimes a list, sometimes not) made the attribute difficult to work with.
|
||||
information. In Django versions prior to 1.3, this included a ``template``
|
||||
attribute containing information about templates rendered in generating the
|
||||
response: either None, a single :class:`~django.template.Template` object, or a
|
||||
list of :class:`~django.template.Template` objects. This inconsistency in
|
||||
return values (sometimes a list, sometimes not) made the attribute difficult
|
||||
to work with.
|
||||
|
||||
In Django 1.3 the :attr:`~django.test.client.Response.template` attribute is
|
||||
deprecated in favor of a new :attr:`~django.test.client.Response.templates`
|
||||
attribute, which is always a list, even if it has only a single element or no
|
||||
elements.
|
||||
In Django 1.3 the ``template`` attribute is deprecated in favor of a new
|
||||
:attr:`~django.test.client.Response.templates` attribute, which is always a
|
||||
list, even if it has only a single element or no elements.
|
||||
|
||||
``DjangoTestRunner``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As a result of the introduction of support for unittest2, the features
|
||||
of :class:`django.test.simple.DjangoTestRunner` (including fail-fast
|
||||
of ``django.test.simple.DjangoTestRunner`` (including fail-fast
|
||||
and Ctrl-C test termination) have been made redundant. In view of this
|
||||
redundancy, :class:`~django.test.simple.DjangoTestRunner` has been
|
||||
turned into an empty placeholder class, and will be removed entirely
|
||||
in Django 1.5.
|
||||
redundancy, ``DjangoTestRunner`` has been turned into an empty placeholder
|
||||
class, and will be removed entirely in Django 1.5.
|
||||
|
||||
The Django 1.3 roadmap
|
||||
======================
|
||||
|
|
|
|||
|
|
@ -142,10 +142,9 @@ Changes to ``USStateField``
|
|||
|
||||
The :mod:`django.contrib.localflavor` application contains collections
|
||||
of code relevant to specific countries or cultures. One such is
|
||||
:class:`~django.contrib.localflavor.us.models.USStateField`, which
|
||||
provides a field for storing the two-letter postal abbreviation of a
|
||||
U.S. state. This field has consistently caused problems, however,
|
||||
because it is often used to store the state portion of a U.S postal
|
||||
``USStateField``, which provides a field for storing the two-letter postal
|
||||
abbreviation of a U.S. state. This field has consistently caused problems,
|
||||
however, because it is often used to store the state portion of a U.S postal
|
||||
address, but not all "states" recognized by the U.S Postal Service are
|
||||
actually states of the U.S. or even U.S. territory. Several
|
||||
compromises over the list of choices resulted in some users feeling
|
||||
|
|
@ -161,7 +160,7 @@ as a pair of changes:
|
|||
choices, plus the U.S. Armed Forces postal codes.
|
||||
|
||||
* A new model field,
|
||||
:class:`django.contrib.localflavor.us.models.USPostalCodeField`, has
|
||||
``django.contrib.localflavor.us.models.USPostalCodeField``, has
|
||||
been added which draws its choices from a list of all postal
|
||||
abbreviations recognized by the U.S Postal Service. This includes
|
||||
all abbreviations recognized by `USStateField`, plus three
|
||||
|
|
|
|||
|
|
@ -700,40 +700,35 @@ As a result of the introduction of class-based generic views, the
|
|||
function-based generic views provided by Django have been deprecated.
|
||||
The following modules and the views they contain have been deprecated:
|
||||
|
||||
* :mod:`django.views.generic.create_update`
|
||||
|
||||
* :mod:`django.views.generic.date_based`
|
||||
|
||||
* :mod:`django.views.generic.list_detail`
|
||||
|
||||
* :mod:`django.views.generic.simple`
|
||||
* ``django.views.generic.create_update``
|
||||
* ``django.views.generic.date_based``
|
||||
* ``django.views.generic.list_detail``
|
||||
* ``django.views.generic.simple``
|
||||
|
||||
Test client response ``template`` attribute
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Django's :ref:`test client <test-client>` returns
|
||||
:class:`~django.test.client.Response` objects annotated with extra testing
|
||||
information. In Django versions prior to 1.3, this included a
|
||||
:attr:`~django.test.client.Response.template` attribute containing information
|
||||
about templates rendered in generating the response: either None, a single
|
||||
:class:`~django.template.Template` object, or a list of
|
||||
:class:`~django.template.Template` objects. This inconsistency in return values
|
||||
(sometimes a list, sometimes not) made the attribute difficult to work with.
|
||||
information. In Django versions prior to 1.3, this included a ``template``
|
||||
attribute containing information about templates rendered in generating the
|
||||
response: either None, a single :class:`~django.template.Template` object, or a
|
||||
list of :class:`~django.template.Template` objects. This inconsistency in
|
||||
return values (sometimes a list, sometimes not) made the attribute difficult
|
||||
to work with.
|
||||
|
||||
In Django 1.3 the :attr:`~django.test.client.Response.template` attribute is
|
||||
deprecated in favor of a new :attr:`~django.test.client.Response.templates`
|
||||
attribute, which is always a list, even if it has only a single element or no
|
||||
elements.
|
||||
In Django 1.3 the ``template`` attribute is deprecated in favor of a new
|
||||
:attr:`~django.test.client.Response.templates` attribute, which is always a
|
||||
list, even if it has only a single element or no elements.
|
||||
|
||||
``DjangoTestRunner``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As a result of the introduction of support for unittest2, the features
|
||||
of :class:`django.test.simple.DjangoTestRunner` (including fail-fast
|
||||
of ``django.test.simple.DjangoTestRunner`` (including fail-fast
|
||||
and Ctrl-C test termination) have been made redundant. In view of this
|
||||
redundancy, :class:`~django.test.simple.DjangoTestRunner` has been
|
||||
turned into an empty placeholder class, and will be removed entirely
|
||||
in Django 1.5.
|
||||
redundancy, ``DjangoTestRunner`` has been turned into an empty placeholder
|
||||
class, and will be removed entirely in Django 1.5.
|
||||
|
||||
Changes to :ttag:`url` and :ttag:`ssi`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -805,9 +800,8 @@ GeoDjango
|
|||
~~~~~~~~~
|
||||
|
||||
* The function-based :setting:`TEST_RUNNER` previously used to execute
|
||||
the GeoDjango test suite,
|
||||
:func:`django.contrib.gis.tests.run_gis_tests`, was deprecated for
|
||||
the class-based runner,
|
||||
the GeoDjango test suite, ``django.contrib.gis.tests.run_gis_tests``, was
|
||||
deprecated for the class-based runner,
|
||||
:class:`django.contrib.gis.tests.GeoDjangoTestSuiteRunner`.
|
||||
|
||||
* Previously, calling
|
||||
|
|
@ -886,11 +880,10 @@ identical to their old versions; only the module location has changed.
|
|||
Removal of ``XMLField``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When Django was first released, Django included an
|
||||
:class:`~django.db.models.XMLField` that performed automatic XML validation
|
||||
for any field input. However, this validation function hasn't been
|
||||
performed since the introduction of ``newforms``, prior to the 1.0 release.
|
||||
As a result, ``XMLField`` as currently implemented is functionally
|
||||
When Django was first released, Django included an ``XMLField`` that performed
|
||||
automatic XML validation for any field input. However, this validation function
|
||||
hasn't been performed since the introduction of ``newforms``, prior to the 1.0
|
||||
release. As a result, ``XMLField`` as currently implemented is functionally
|
||||
indistinguishable from a simple :class:`~django.db.models.TextField`.
|
||||
|
||||
For this reason, Django 1.3 has fast-tracked the deprecation of
|
||||
|
|
|
|||
|
|
@ -503,7 +503,7 @@ Django 1.4 also includes several smaller improvements worth noting:
|
|||
* In the documentation, a helpful :doc:`security overview </topics/security>`
|
||||
page.
|
||||
|
||||
* The :func:`django.contrib.auth.models.check_password` function has been moved
|
||||
* The ``django.contrib.auth.models.check_password`` function has been moved
|
||||
to the :mod:`django.contrib.auth.utils` module. Importing it from the old
|
||||
location will still work, but you should update your imports.
|
||||
|
||||
|
|
|
|||
|
|
@ -563,7 +563,7 @@ Django 1.4 also includes several smaller improvements worth noting:
|
|||
* In the documentation, a helpful :doc:`security overview </topics/security>`
|
||||
page.
|
||||
|
||||
* The :func:`django.contrib.auth.models.check_password` function has been moved
|
||||
* The ``django.contrib.auth.models.check_password`` function has been moved
|
||||
to the :mod:`django.contrib.auth.utils` module. Importing it from the old
|
||||
location will still work, but you should update your imports.
|
||||
|
||||
|
|
|
|||
|
|
@ -585,7 +585,7 @@ Django 1.4 also includes several smaller improvements worth noting:
|
|||
* In the documentation, a helpful :doc:`security overview </topics/security>`
|
||||
page.
|
||||
|
||||
* The :func:`django.contrib.auth.models.check_password` function has been moved
|
||||
* The ``django.contrib.auth.models.check_password`` function has been moved
|
||||
to the :mod:`django.contrib.auth.hashers` module. Importing it from the old
|
||||
location will still work, but you should update your imports.
|
||||
|
||||
|
|
|
|||
|
|
@ -423,7 +423,7 @@ More information on these incompatibilities is available in `ticket #18023`_.
|
|||
|
||||
The net result is that, if you have installed :mod:`simplejson` and your code
|
||||
uses Django's serialization internals directly -- for instance
|
||||
:class:`django.core.serializers.json.DjangoJSONEncoder`, the switch from
|
||||
``django.core.serializers.json.DjangoJSONEncoder``, the switch from
|
||||
:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
|
||||
internals aren't documented; we're making an exception here.)
|
||||
|
||||
|
|
@ -449,8 +449,8 @@ When using :doc:`object pagination </topics/pagination>`,
|
|||
the ``previous_page_number()`` and ``next_page_number()`` methods of the
|
||||
:class:`~django.core.paginator.Page` object did not check if the returned
|
||||
number was inside the existing page range.
|
||||
It does check it now and raises an :exc:`InvalidPage` exception when the number
|
||||
is either too low or too high.
|
||||
It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
|
||||
exception when the number is either too low or too high.
|
||||
|
||||
Behavior of autocommit database option on PostgreSQL changed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -619,10 +619,9 @@ Define a ``__str__`` method and apply the
|
|||
``django.utils.itercompat.product``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
|
||||
The ``django.utils.itercompat.product`` function has been deprecated. Use
|
||||
the built-in :func:`itertools.product` instead.
|
||||
|
||||
|
||||
``django.utils.markup``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -448,7 +448,7 @@ More information on these incompatibilities is available in `ticket #18023`_.
|
|||
|
||||
The net result is that, if you have installed :mod:`simplejson` and your code
|
||||
uses Django's serialization internals directly -- for instance
|
||||
:class:`django.core.serializers.json.DjangoJSONEncoder`, the switch from
|
||||
``django.core.serializers.json.DjangoJSONEncoder``, the switch from
|
||||
:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
|
||||
internals aren't documented; we're making an exception here.)
|
||||
|
||||
|
|
@ -474,8 +474,8 @@ When using :doc:`object pagination </topics/pagination>`,
|
|||
the ``previous_page_number()`` and ``next_page_number()`` methods of the
|
||||
:class:`~django.core.paginator.Page` object did not check if the returned
|
||||
number was inside the existing page range.
|
||||
It does check it now and raises an :exc:`InvalidPage` exception when the number
|
||||
is either too low or too high.
|
||||
It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
|
||||
exception when the number is either too low or too high.
|
||||
|
||||
Behavior of autocommit database option on PostgreSQL changed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -672,7 +672,7 @@ Define a ``__str__`` method and apply the
|
|||
``django.utils.itercompat.product``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
|
||||
The ``django.utils.itercompat.product`` function has been deprecated. Use
|
||||
the built-in :func:`itertools.product` instead.
|
||||
|
||||
``django.utils.markup``
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Some features of Django aren't available because they depend on third-party
|
|||
software that hasn't been ported to Python 3 yet, including:
|
||||
|
||||
- the MySQL database backend (depends on MySQLdb)
|
||||
- :class:`~django.db.models.fields.ImageField` (depends on PIL)
|
||||
- :class:`~django.db.models.ImageField` (depends on PIL)
|
||||
- :class:`~django.test.LiveServerTestCase` (depends on Selenium WebDriver)
|
||||
|
||||
Further, Django's more than a web framework; it's an ecosystem of pluggable
|
||||
|
|
@ -469,7 +469,7 @@ More information on these incompatibilities is available in `ticket #18023`_.
|
|||
|
||||
The net result is that, if you have installed :mod:`simplejson` and your code
|
||||
uses Django's serialization internals directly -- for instance
|
||||
:class:`django.core.serializers.json.DjangoJSONEncoder`, the switch from
|
||||
``django.core.serializers.json.DjangoJSONEncoder``, the switch from
|
||||
:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
|
||||
internals aren't documented; we're making an exception here.)
|
||||
|
||||
|
|
@ -495,8 +495,8 @@ When using :doc:`object pagination </topics/pagination>`,
|
|||
the ``previous_page_number()`` and ``next_page_number()`` methods of the
|
||||
:class:`~django.core.paginator.Page` object did not check if the returned
|
||||
number was inside the existing page range.
|
||||
It does check it now and raises an :exc:`InvalidPage` exception when the number
|
||||
is either too low or too high.
|
||||
It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
|
||||
exception when the number is either too low or too high.
|
||||
|
||||
Behavior of autocommit database option on PostgreSQL changed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -714,7 +714,7 @@ Define a ``__str__`` method and apply the
|
|||
``django.utils.itercompat.product``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
|
||||
The ``django.utils.itercompat.product`` function has been deprecated. Use
|
||||
the built-in :func:`itertools.product` instead.
|
||||
|
||||
``cleanup`` management command
|
||||
|
|
|
|||
|
|
@ -93,8 +93,8 @@ DetailView: working with a single Django object
|
|||
|
||||
To show the detail of an object, we basically need to do two things:
|
||||
we need to look up the object and then we need to make a
|
||||
:class:`TemplateResponse` with a suitable template, and that object as
|
||||
context.
|
||||
:class:`~django.template.response.TemplateResponse` with a suitable template,
|
||||
and that object as context.
|
||||
|
||||
To get the object, :class:`~django.views.generic.detail.DetailView`
|
||||
relies on :class:`~django.views.generic.detail.SingleObjectMixin`,
|
||||
|
|
@ -111,15 +111,14 @@ attribute if that's provided). :class:`SingleObjectMixin` also overrides
|
|||
which is used across all Django's built in class-based views to supply
|
||||
context data for template renders.
|
||||
|
||||
To then make a :class:`TemplateResponse`, :class:`DetailView` uses
|
||||
To then make a :class:`~django.template.response.TemplateResponse`,
|
||||
:class:`DetailView` uses
|
||||
:class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`,
|
||||
which extends
|
||||
:class:`~django.views.generic.base.TemplateResponseMixin`, overriding
|
||||
:meth:`get_template_names()` as discussed above. It actually provides
|
||||
a fairly sophisticated set of options, but the main one that most
|
||||
people are going to use is
|
||||
``<app_label>/<object_name>_detail.html``. The ``_detail`` part can be
|
||||
changed by setting
|
||||
which extends :class:`~django.views.generic.base.TemplateResponseMixin`,
|
||||
overriding :meth:`get_template_names()` as discussed above. It actually
|
||||
provides a fairly sophisticated set of options, but the main one that most
|
||||
people are going to use is ``<app_label>/<object_name>_detail.html``. The
|
||||
``_detail`` part can be changed by setting
|
||||
:attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
|
||||
on a subclass to something else. (For instance, the :doc:`generic edit
|
||||
views<generic-editing>` use ``_form`` for create and update views, and
|
||||
|
|
@ -265,7 +264,7 @@ We can hook this into our URLs easily enough::
|
|||
|
||||
Note the ``pk`` named group, which
|
||||
:meth:`~django.views.generic.detail.SingleObjectMixin.get_object` uses
|
||||
to look up the :class:`Author` instance. You could also use a slug, or
|
||||
to look up the ``Author`` instance. You could also use a slug, or
|
||||
any of the other features of :class:`SingleObjectMixin`.
|
||||
|
||||
Using SingleObjectMixin with ListView
|
||||
|
|
@ -299,7 +298,7 @@ object. In order to do this, we need to have two different querysets:
|
|||
will add in the suitable ``page_obj`` and ``paginator`` for us
|
||||
providing we remember to call ``super()``.
|
||||
|
||||
Now we can write a new :class:`PublisherDetail`::
|
||||
Now we can write a new ``PublisherDetail``::
|
||||
|
||||
from django.views.generic import ListView
|
||||
from django.views.generic.detail import SingleObjectMixin
|
||||
|
|
@ -403,7 +402,7 @@ At this point it's natural to reach for a :class:`Form` to encapsulate
|
|||
the information sent from the user's browser to Django. Say also that
|
||||
we're heavily invested in `REST`_, so we want to use the same URL for
|
||||
displaying the author as for capturing the message from the
|
||||
user. Let's rewrite our :class:`AuthorDetailView` to do that.
|
||||
user. Let's rewrite our ``AuthorDetailView`` to do that.
|
||||
|
||||
.. _REST: http://en.wikipedia.org/wiki/Representational_state_transfer
|
||||
|
||||
|
|
@ -423,7 +422,7 @@ code so that on ``POST`` the form gets called appropriately.
|
|||
|
||||
.. highlightlang:: python
|
||||
|
||||
Our new :class:`AuthorDetail` looks like this::
|
||||
Our new ``AuthorDetail`` looks like this::
|
||||
|
||||
# CAUTION: you almost certainly do not want to do this.
|
||||
# It is provided as part of a discussion of problems you can
|
||||
|
|
@ -507,10 +506,10 @@ clear division here: ``GET`` requests should get the
|
|||
data), and ``POST`` requests should get the :class:`FormView`. Let's
|
||||
set up those views first.
|
||||
|
||||
The :class:`AuthorDisplay` view is almost the same as :ref:`when we
|
||||
The ``AuthorDisplay`` view is almost the same as :ref:`when we
|
||||
first introduced AuthorDetail<generic-views-extra-work>`; we have to
|
||||
write our own :meth:`get_context_data()` to make the
|
||||
:class:`AuthorInterestForm` available to the template. We'll skip the
|
||||
``AuthorInterestForm`` available to the template. We'll skip the
|
||||
:meth:`get_object()` override from before for clarity.
|
||||
|
||||
.. code-block:: python
|
||||
|
|
@ -533,11 +532,11 @@ write our own :meth:`get_context_data()` to make the
|
|||
context.update(kwargs)
|
||||
return super(AuthorDisplay, self).get_context_data(**context)
|
||||
|
||||
Then the :class:`AuthorInterest` is a simple :class:`FormView`, but we
|
||||
Then the ``AuthorInterest`` is a simple :class:`FormView`, but we
|
||||
have to bring in :class:`SingleObjectMixin` so we can find the author
|
||||
we're talking about, and we have to remember to set
|
||||
:attr:`template_name` to ensure that form errors will render the same
|
||||
template as :class:`AuthorDisplay` is using on ``GET``.
|
||||
template as ``AuthorDisplay`` is using on ``GET``.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
@ -568,14 +567,14 @@ template as :class:`AuthorDisplay` is using on ``GET``.
|
|||
# record the interest using the message in form.cleaned_data
|
||||
return super(AuthorInterest, self).form_valid(form)
|
||||
|
||||
Finally we bring this together in a new :class:`AuthorDetail` view. We
|
||||
Finally we bring this together in a new ``AuthorDetail`` view. We
|
||||
already know that calling :meth:`as_view()` on a class-based view
|
||||
gives us something that behaves exactly like a function based view, so
|
||||
we can do that at the point we choose between the two subviews.
|
||||
|
||||
You can of course pass through keyword arguments to :meth:`as_view()`
|
||||
in the same way you would in your URLconf, such as if you wanted the
|
||||
:class:`AuthorInterest` behaviour to also appear at another URL but
|
||||
``AuthorInterest`` behaviour to also appear at another URL but
|
||||
using a different template.
|
||||
|
||||
.. code-block:: python
|
||||
|
|
|
|||
|
|
@ -601,6 +601,8 @@ relation may end up filtering on different linked objects.
|
|||
Filters can reference fields on the model
|
||||
-----------------------------------------
|
||||
|
||||
.. class:: F
|
||||
|
||||
In the examples given so far, we have constructed filters that compare
|
||||
the value of a model field with a constant. But what if you want to compare
|
||||
the value of a model field with another field on the same model?
|
||||
|
|
@ -755,6 +757,8 @@ To avoid this problem, simply save the
|
|||
Complex lookups with Q objects
|
||||
==============================
|
||||
|
||||
.. class:: Q
|
||||
|
||||
Keyword argument queries -- in :meth:`~django.db.models.query.QuerySet.filter`,
|
||||
etc. -- are "AND"ed together. If you need to execute more complex queries (for
|
||||
example, queries with ``OR`` statements), you can use ``Q`` objects.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ display two blank forms::
|
|||
|
||||
Iterating over the ``formset`` will render the forms in the order they were
|
||||
created. You can change this order by providing an alternate implementation for
|
||||
the :meth:`__iter__()` method.
|
||||
the ``__iter__()`` method.
|
||||
|
||||
Formsets can also be indexed into, which returns the corresponding form. If you
|
||||
override ``__iter__``, you will need to also override ``__getitem__`` to have
|
||||
|
|
|
|||
|
|
@ -300,9 +300,9 @@ loop::
|
|||
<p><input type="submit" value="Send message" /></p>
|
||||
</form>
|
||||
|
||||
Within this loop, ``{{ field }}`` is an instance of :class:`BoundField`.
|
||||
``BoundField`` also has the following attributes, which can be useful in your
|
||||
templates:
|
||||
Within this loop, ``{{ field }}`` is an instance of
|
||||
:class:`~django.forms.BoundField`. ``BoundField`` also has the following
|
||||
attributes, which can be useful in your templates:
|
||||
|
||||
``{{ field.label }}``
|
||||
The label of the field, e.g. ``Email address``.
|
||||
|
|
|
|||
|
|
@ -549,6 +549,8 @@ model's ``clean()`` hook.
|
|||
Model formsets
|
||||
==============
|
||||
|
||||
.. class:: models.BaseModelFormSet
|
||||
|
||||
Like :doc:`regular formsets </topics/forms/formsets>`, Django provides a couple
|
||||
of enhanced formset classes that make it easy to work with Django models. Let's
|
||||
reuse the ``Author`` model from above::
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ You can edit it multiple times.
|
|||
- ``modification``: last modification of the session, as a
|
||||
:class:`~datetime.datetime` object. Defaults to the current time.
|
||||
- ``expiry``: expiry information for the session, as a
|
||||
:class:`~datetime.datetime` object, an :class:`int` (in seconds), or
|
||||
:class:`~datetime.datetime` object, an :func:`int` (in seconds), or
|
||||
``None``. Defaults to the value stored in the session by
|
||||
:meth:`set_expiry`, if there is one, or ``None``.
|
||||
|
||||
|
|
|
|||
|
|
@ -1248,6 +1248,8 @@ The ``set_language`` redirect view
|
|||
|
||||
.. highlightlang:: python
|
||||
|
||||
.. currentmodule:: django.views.i18n
|
||||
|
||||
.. function:: set_language(request)
|
||||
|
||||
As a convenience, Django comes with a view, :func:`django.views.i18n.set_language`,
|
||||
|
|
|
|||
|
|
@ -853,7 +853,7 @@ Normal Python unit test classes extend a base class of
|
|||
Hierarchy of Django unit testing classes
|
||||
|
||||
Regardless of the version of Python you're using, if you've installed
|
||||
:mod:`unittest2`, :mod:`django.utils.unittest` will point to that library.
|
||||
``unittest2``, :mod:`django.utils.unittest` will point to that library.
|
||||
|
||||
SimpleTestCase
|
||||
~~~~~~~~~~~~~~
|
||||
|
|
@ -1376,7 +1376,7 @@ in the ``with`` block and reset its value to the previous state afterwards.
|
|||
.. function:: override_settings
|
||||
|
||||
In case you want to override a setting for just one test method or even the
|
||||
whole :class:`TestCase` class, Django provides the
|
||||
whole :class:`~django.test.TestCase` class, Django provides the
|
||||
:func:`~django.test.utils.override_settings` decorator (see :pep:`318`). It's
|
||||
used like this::
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue