mirror of
https://github.com/django/django.git
synced 2025-08-04 02:48:35 +00:00
Fixed #26124 -- Added missing code formatting to docs headers.
This commit is contained in:
rowanv
Tim Graham
parent
8bf8d0e0ec
commit
a6ef025dfb
93 changed files with 1658 additions and 1625 deletions
|
|
@ -289,8 +289,8 @@ example, the following checks if a user may view tasks::
|
|||
|
||||
.. _extending-user:
|
||||
|
||||
Extending the existing User model
|
||||
=================================
|
||||
Extending the existing ``User`` model
|
||||
=====================================
|
||||
|
||||
There are two ways to extend the default
|
||||
:class:`~django.contrib.auth.models.User` model without substituting your own
|
||||
|
|
@ -360,8 +360,8 @@ the extra database load.
|
|||
|
||||
.. _auth-custom-user:
|
||||
|
||||
Substituting a custom User model
|
||||
================================
|
||||
Substituting a custom ``User`` model
|
||||
====================================
|
||||
|
||||
Some kinds of projects may have authentication requirements for which Django's
|
||||
built-in :class:`~django.contrib.auth.models.User` model is not always
|
||||
|
|
@ -414,8 +414,8 @@ use as your User model.
|
|||
:class:`~django.db.models.OneToOneField` to ``settings.AUTH_USER_MODEL``
|
||||
as described below.
|
||||
|
||||
Referencing the User model
|
||||
--------------------------
|
||||
Referencing the ``User`` model
|
||||
------------------------------
|
||||
|
||||
.. currentmodule:: django.contrib.auth
|
||||
|
||||
|
|
@ -462,8 +462,8 @@ different User model.
|
|||
|
||||
.. _specifying-custom-user-model:
|
||||
|
||||
Specifying a custom User model
|
||||
------------------------------
|
||||
Specifying a custom ``User`` model
|
||||
----------------------------------
|
||||
|
||||
.. admonition:: Model design considerations
|
||||
|
||||
|
|
@ -716,8 +716,8 @@ utility methods:
|
|||
* ``o``, ``O``, and ``0`` (lowercase letter o, uppercase letter o,
|
||||
and zero)
|
||||
|
||||
Extending Django's default User
|
||||
-------------------------------
|
||||
Extending Django's default ``User``
|
||||
-----------------------------------
|
||||
|
||||
If you're entirely happy with Django's :class:`~django.contrib.auth.models.User`
|
||||
model and you just want to add some additional profile information, you could
|
||||
|
|
@ -875,16 +875,16 @@ methods and attributes:
|
|||
(the Django app label). If the user is inactive, this method will
|
||||
always return ``False``.
|
||||
|
||||
.. admonition:: ModelBackend
|
||||
.. admonition:: ``PermissionsMixin`` and ``ModelBackend``
|
||||
|
||||
If you don't include the
|
||||
:class:`~django.contrib.auth.models.PermissionsMixin`, you must ensure you
|
||||
don't invoke the permissions methods on ``ModelBackend``. ``ModelBackend``
|
||||
assumes that certain fields are available on your user model. If your User
|
||||
model doesn't provide those fields, you will receive database errors when
|
||||
you check permissions.
|
||||
assumes that certain fields are available on your user model. If your
|
||||
``User`` model doesn't provide those fields, you will receive database
|
||||
errors when you check permissions.
|
||||
|
||||
Custom users and Proxy models
|
||||
Custom users and proxy models
|
||||
-----------------------------
|
||||
|
||||
One limitation of custom User models is that installing a custom User model
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ are somewhat coupled.
|
|||
|
||||
.. _user-objects:
|
||||
|
||||
User objects
|
||||
============
|
||||
``User`` objects
|
||||
================
|
||||
|
||||
:class:`~django.contrib.auth.models.User` objects are the core of the
|
||||
authentication system. They typically represent the people interacting with
|
||||
|
|
@ -112,7 +112,7 @@ passwords.
|
|||
Changing a user's password will log out all their sessions. See
|
||||
:ref:`session-invalidation-on-password-change` for details.
|
||||
|
||||
Authenticating Users
|
||||
Authenticating users
|
||||
--------------------
|
||||
|
||||
.. function:: authenticate(\**credentials)
|
||||
|
|
@ -363,13 +363,14 @@ If you have an authenticated user you want to attach to the current session
|
|||
:func:`~django.contrib.auth.login()`. Now you can set the backend using
|
||||
the new ``backend`` argument.
|
||||
|
||||
Selecting the :ref:`authentication backend <authentication-backends>`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Selecting the authentication backend
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When a user logs in, the user's ID and the backend that was used for
|
||||
authentication are saved in the user's session. This allows the same
|
||||
authentication backend to fetch the user's details on a future request. The
|
||||
authentication backend to save in the session is selected as follows:
|
||||
:ref:`authentication backend <authentication-backends>` to fetch the user's
|
||||
details on a future request. The authentication backend to save in the session
|
||||
is selected as follows:
|
||||
|
||||
#. Use the value of the optional ``backend`` argument, if provided.
|
||||
#. Use the value of the ``user.backend`` attribute, if present. This allows
|
||||
|
|
@ -1673,7 +1674,7 @@ model. Groups can be created, and permissions can be assigned to users or
|
|||
groups. A log of user edits to models made within the admin is also stored and
|
||||
displayed.
|
||||
|
||||
Creating Users
|
||||
Creating users
|
||||
--------------
|
||||
|
||||
You should see a link to "Users" in the "Auth"
|
||||
|
|
@ -1695,7 +1696,7 @@ non-superuser the ability to edit users, this is ultimately the same as giving
|
|||
them superuser status because they will be able to elevate permissions of
|
||||
users including themselves!
|
||||
|
||||
Changing Passwords
|
||||
Changing passwords
|
||||
------------------
|
||||
|
||||
User passwords are not displayed in the admin (nor stored in the database), but
|
||||
|
|
|
|||
|
|
@ -74,8 +74,8 @@ setting.
|
|||
|
||||
.. _bcrypt_usage:
|
||||
|
||||
Using bcrypt with Django
|
||||
------------------------
|
||||
Using ``bcrypt`` with Django
|
||||
----------------------------
|
||||
|
||||
Bcrypt_ is a popular password storage algorithm that's specifically designed
|
||||
for long-term password storage. It's not the default used by Django since it
|
||||
|
|
|
|||
|
|
@ -1049,8 +1049,8 @@ pages. We'll look at some of these headers in the sections that follow.
|
|||
|
||||
.. _using-vary-headers:
|
||||
|
||||
Using Vary headers
|
||||
==================
|
||||
Using ``Vary`` headers
|
||||
======================
|
||||
|
||||
The ``Vary`` header defines which request headers a cache
|
||||
mechanism should take into account when building its cache key. For example, if
|
||||
|
|
@ -1231,8 +1231,8 @@ Example::
|
|||
|
||||
.. _`Cache-Control spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
|
||||
|
||||
Order of MIDDLEWARE_CLASSES
|
||||
===========================
|
||||
Order of ``MIDDLEWARE_CLASSES``
|
||||
===============================
|
||||
|
||||
If you use caching middleware, it's important to put each half in the right
|
||||
place within the :setting:`MIDDLEWARE_CLASSES` setting. That's because the cache
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ The code below is equivalent to the code above::
|
|||
|
||||
.. _field-checking:
|
||||
|
||||
Field, Model, and Manager checks
|
||||
Field, model, and manager checks
|
||||
--------------------------------
|
||||
|
||||
In some cases, you won't need to register your check function -- you can
|
||||
|
|
@ -185,7 +185,7 @@ the only difference is that the check is a classmethod, not an instance method::
|
|||
# ... your own checks ...
|
||||
return errors
|
||||
|
||||
Writing Tests
|
||||
Writing tests
|
||||
-------------
|
||||
|
||||
Messages are comparable. That allows you to easily write tests::
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Implementing this yourself often results in a lot of repeated boilerplate code
|
|||
this, Django provides a collection of generic class-based views for form
|
||||
processing.
|
||||
|
||||
Basic Forms
|
||||
Basic forms
|
||||
===========
|
||||
|
||||
Given a simple contact form:
|
||||
|
|
@ -60,7 +60,7 @@ Notes:
|
|||
:meth:`~django.views.generic.edit.FormMixin.form_valid` simply
|
||||
redirects to the :attr:`~django.views.generic.edit.FormMixin.success_url`.
|
||||
|
||||
Model Forms
|
||||
Model forms
|
||||
===========
|
||||
|
||||
Generic views really shine when working with models. These generic
|
||||
|
|
@ -180,8 +180,8 @@ Finally, we hook these new views into the URLconf:
|
|||
:attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
|
||||
on your view class.
|
||||
|
||||
Models and request.user
|
||||
=======================
|
||||
Models and ``request.user``
|
||||
===========================
|
||||
|
||||
To track the user that created an object using a :class:`CreateView`,
|
||||
you can use a custom :class:`~django.forms.ModelForm` to do this. First, add
|
||||
|
|
|
|||
|
|
@ -86,8 +86,8 @@ date-based generic views. These are
|
|||
covered in the :doc:`mixin reference
|
||||
documentation</ref/class-based-views/mixins>`.
|
||||
|
||||
DetailView: working with a single Django object
|
||||
-----------------------------------------------
|
||||
``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
|
||||
|
|
@ -124,8 +124,8 @@ on a subclass to something else. (For instance, the :doc:`generic edit
|
|||
views<generic-editing>` use ``_form`` for create and update views, and
|
||||
``_confirm_delete`` for delete views.)
|
||||
|
||||
ListView: working with many Django objects
|
||||
------------------------------------------
|
||||
``ListView``: working with many Django objects
|
||||
----------------------------------------------
|
||||
|
||||
Lists of objects follow roughly the same pattern: we need a (possibly
|
||||
paginated) list of objects, typically a
|
||||
|
|
@ -208,8 +208,8 @@ the box.
|
|||
|
||||
.. _method resolution order: https://www.python.org/download/releases/2.3/mro/
|
||||
|
||||
Using SingleObjectMixin with View
|
||||
---------------------------------
|
||||
Using ``SingleObjectMixin`` with View
|
||||
-------------------------------------
|
||||
|
||||
If we want to write a simple class-based view that responds only to
|
||||
``POST``, we'll subclass :class:`~django.views.generic.base.View` and
|
||||
|
|
@ -271,8 +271,8 @@ to look up the ``Author`` instance. You could also use a slug, or
|
|||
any of the other features of
|
||||
:class:`~django.views.generic.detail.SingleObjectMixin`.
|
||||
|
||||
Using SingleObjectMixin with ListView
|
||||
-------------------------------------
|
||||
Using ``SingleObjectMixin`` with ``ListView``
|
||||
---------------------------------------------
|
||||
|
||||
:class:`~django.views.generic.list.ListView` provides built-in
|
||||
pagination, but you might want to paginate a list of objects that are
|
||||
|
|
@ -404,8 +404,8 @@ is a simpler solution. First, let's look at a naive attempt to combine
|
|||
``POST`` a Django :class:`~django.forms.Form` to the same URL as we're
|
||||
displaying an object using :class:`DetailView`.
|
||||
|
||||
Using FormMixin with DetailView
|
||||
-------------------------------
|
||||
Using ``FormMixin`` with ``DetailView``
|
||||
---------------------------------------
|
||||
|
||||
Think back to our earlier example of using :class:`View` and
|
||||
:class:`~django.views.generic.detail.SingleObjectMixin` together. We were
|
||||
|
|
|
|||
|
|
@ -88,8 +88,8 @@ In a hurry? Here's how to do common aggregate queries, assuming the models above
|
|||
>>> pubs[0].num_books
|
||||
1323
|
||||
|
||||
Generating aggregates over a QuerySet
|
||||
=====================================
|
||||
Generating aggregates over a ``QuerySet``
|
||||
=========================================
|
||||
|
||||
Django provides two ways to generate aggregates. The first way is to generate
|
||||
summary values over an entire ``QuerySet``. For example, say you wanted to
|
||||
|
|
@ -134,8 +134,8 @@ the maximum and minimum price of all books, we would issue the query::
|
|||
>>> Book.objects.aggregate(Avg('price'), Max('price'), Min('price'))
|
||||
{'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}
|
||||
|
||||
Generating aggregates for each item in a QuerySet
|
||||
=================================================
|
||||
Generating aggregates for each item in a ``QuerySet``
|
||||
=====================================================
|
||||
|
||||
The second way to generate summary values is to generate an independent
|
||||
summary for each object in a ``QuerySet``. For example, if you are retrieving
|
||||
|
|
@ -297,8 +297,8 @@ file::
|
|||
(The resulting dictionary will have a key called ``'average__rating'``. If no
|
||||
such alias were specified, it would be the rather long ``'book__rating__avg'``.)
|
||||
|
||||
Aggregations and other QuerySet clauses
|
||||
=======================================
|
||||
Aggregations and other ``QuerySet`` clauses
|
||||
===========================================
|
||||
|
||||
``filter()`` and ``exclude()``
|
||||
------------------------------
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ of all ``Person`` objects.
|
|||
|
||||
.. _custom-managers:
|
||||
|
||||
Custom Managers
|
||||
Custom managers
|
||||
===============
|
||||
|
||||
You can use a custom ``Manager`` in a particular model by extending the base
|
||||
|
|
@ -47,7 +47,7 @@ There are two reasons you might want to customize a ``Manager``: to add extra
|
|||
``Manager`` methods, and/or to modify the initial ``QuerySet`` the ``Manager``
|
||||
returns.
|
||||
|
||||
Adding extra Manager methods
|
||||
Adding extra manager methods
|
||||
----------------------------
|
||||
|
||||
Adding extra ``Manager`` methods is the preferred way to add "table-level"
|
||||
|
|
@ -97,8 +97,8 @@ that list of ``OpinionPoll`` objects with ``num_responses`` attributes.
|
|||
Another thing to note about this example is that ``Manager`` methods can
|
||||
access ``self.model`` to get the model class to which they're attached.
|
||||
|
||||
Modifying initial Manager QuerySets
|
||||
-----------------------------------
|
||||
Modifying a manager's initial ``QuerySet``
|
||||
------------------------------------------
|
||||
|
||||
A ``Manager``’s base ``QuerySet`` returns all objects in the system. For
|
||||
example, using this model::
|
||||
|
|
@ -204,8 +204,8 @@ attribute on the manager class. This is documented fully below_.
|
|||
|
||||
.. _calling-custom-queryset-methods-from-manager:
|
||||
|
||||
Calling custom ``QuerySet`` methods from the ``Manager``
|
||||
--------------------------------------------------------
|
||||
Calling custom ``QuerySet`` methods from the manager
|
||||
----------------------------------------------------
|
||||
|
||||
While most methods from the standard ``QuerySet`` are accessible directly from
|
||||
the ``Manager``, this is only the case for the extra methods defined on a
|
||||
|
|
@ -239,8 +239,8 @@ the manager ``Person.people``.
|
|||
|
||||
.. _create-manager-with-queryset-methods:
|
||||
|
||||
Creating ``Manager`` with ``QuerySet`` methods
|
||||
----------------------------------------------
|
||||
Creating a manager with ``QuerySet`` methods
|
||||
--------------------------------------------
|
||||
|
||||
In lieu of the above approach which requires duplicating methods on both the
|
||||
``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
|
||||
|
|
@ -288,8 +288,8 @@ For example::
|
|||
return
|
||||
_opted_in_private_method.queryset_only = False
|
||||
|
||||
from_queryset
|
||||
~~~~~~~~~~~~~
|
||||
``from_queryset()``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. classmethod:: from_queryset(queryset_class)
|
||||
|
||||
|
|
@ -438,7 +438,7 @@ be copied.
|
|||
|
||||
.. _manager-types:
|
||||
|
||||
Controlling automatic Manager types
|
||||
Controlling automatic manager types
|
||||
===================================
|
||||
|
||||
This document has already mentioned a couple of places where Django creates a
|
||||
|
|
@ -484,7 +484,7 @@ it will use :class:`django.db.models.Manager`.
|
|||
so that existing code will :doc:`continue to work </misc/api-stability>` in
|
||||
future Django versions.
|
||||
|
||||
Writing correct Managers for use in automatic Manager instances
|
||||
Writing correct managers for use in automatic manager instances
|
||||
---------------------------------------------------------------
|
||||
|
||||
The ``use_for_related_fields`` feature is primarily for managers that need to
|
||||
|
|
|
|||
|
|
@ -686,8 +686,8 @@ provided in :doc:`/howto/custom-model-fields`.
|
|||
|
||||
.. _meta-options:
|
||||
|
||||
Meta options
|
||||
============
|
||||
``Meta`` options
|
||||
================
|
||||
|
||||
Give your model metadata by using an inner ``class Meta``, like so::
|
||||
|
||||
|
|
@ -1215,8 +1215,8 @@ order by the ``last_name`` attribute when you use the proxy. This is easy::
|
|||
Now normal ``Person`` queries will be unordered
|
||||
and ``OrderedPerson`` queries will be ordered by ``last_name``.
|
||||
|
||||
QuerySets still return the model that was requested
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
``QuerySet``\s still return the model that was requested
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There is no way to have Django return, say, a ``MyPerson`` object whenever you
|
||||
query for ``Person`` objects. A queryset for ``Person`` objects will return
|
||||
|
|
|
|||
|
|
@ -58,14 +58,14 @@ work. This document also does not address other optimization techniques that
|
|||
apply to all expensive operations, such as :doc:`general purpose caching
|
||||
</topics/cache>`.
|
||||
|
||||
Understand QuerySets
|
||||
====================
|
||||
Understand ``QuerySet``\s
|
||||
=========================
|
||||
|
||||
Understanding :doc:`QuerySets </ref/models/querysets>` is vital to getting good
|
||||
performance with simple code. In particular:
|
||||
|
||||
Understand QuerySet evaluation
|
||||
------------------------------
|
||||
Understand ``QuerySet`` evaluation
|
||||
----------------------------------
|
||||
|
||||
To avoid performance problems, it is important to understand:
|
||||
|
||||
|
|
@ -232,13 +232,13 @@ are most useful when you can avoid loading a lot of text data or for fields
|
|||
that might take a lot of processing to convert back to Python. As always,
|
||||
profile first, then optimize.
|
||||
|
||||
Use QuerySet.count()
|
||||
--------------------
|
||||
Use ``QuerySet.count()``
|
||||
------------------------
|
||||
|
||||
...if you only want the count, rather than doing ``len(queryset)``.
|
||||
|
||||
Use QuerySet.exists()
|
||||
---------------------
|
||||
Use ``QuerySet.exists()``
|
||||
-------------------------
|
||||
|
||||
...if you only want to find out if at least one result exists, rather than ``if
|
||||
queryset``.
|
||||
|
|
|
|||
|
|
@ -239,8 +239,8 @@ January 30, 2005, and the current day.
|
|||
|
||||
.. _filtered-querysets-are-unique:
|
||||
|
||||
Filtered QuerySets are unique
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Filtered ``QuerySet``\s are unique
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Each time you refine a :class:`~django.db.models.query.QuerySet`, you get a
|
||||
brand-new :class:`~django.db.models.query.QuerySet` that is in no way bound to
|
||||
|
|
@ -265,8 +265,8 @@ refinement process.
|
|||
|
||||
.. _querysets-are-lazy:
|
||||
|
||||
QuerySets are lazy
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
``QuerySet``\s are lazy
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
``QuerySets`` are lazy -- the act of creating a
|
||||
:class:`~django.db.models.query.QuerySet` doesn't involve any database
|
||||
|
|
@ -287,11 +287,10 @@ until you "ask" for them. When you do, the
|
|||
database. For more details on exactly when evaluation takes place, see
|
||||
:ref:`when-querysets-are-evaluated`.
|
||||
|
||||
|
||||
.. _retrieving-single-object-with-get:
|
||||
|
||||
Retrieving a single object with get
|
||||
-----------------------------------
|
||||
Retrieving a single object with ``get()``
|
||||
-----------------------------------------
|
||||
|
||||
:meth:`~django.db.models.query.QuerySet.filter` will always give you a
|
||||
:class:`~django.db.models.query.QuerySet`, even if only a single object matches
|
||||
|
|
@ -324,8 +323,8 @@ Similarly, Django will complain if more than one item matches the
|
|||
attribute of the model class itself.
|
||||
|
||||
|
||||
Other QuerySet methods
|
||||
----------------------
|
||||
Other ``QuerySet`` methods
|
||||
--------------------------
|
||||
|
||||
Most of the time you'll use :meth:`~django.db.models.query.QuerySet.all`,
|
||||
:meth:`~django.db.models.query.QuerySet.get`,
|
||||
|
|
@ -337,8 +336,8 @@ various :class:`~django.db.models.query.QuerySet` methods.
|
|||
|
||||
.. _limiting-querysets:
|
||||
|
||||
Limiting QuerySets
|
||||
------------------
|
||||
Limiting ``QuerySet``\s
|
||||
-----------------------
|
||||
|
||||
Use a subset of Python's array-slicing syntax to limit your
|
||||
:class:`~django.db.models.query.QuerySet` to a certain number of results. This
|
||||
|
|
@ -663,8 +662,8 @@ The ``F()`` objects support bitwise operations by ``.bitand()`` and
|
|||
|
||||
>>> F('somefield').bitand(16)
|
||||
|
||||
The pk lookup shortcut
|
||||
----------------------
|
||||
The ``pk`` lookup shortcut
|
||||
--------------------------
|
||||
|
||||
For convenience, Django provides a ``pk`` lookup shortcut, which stands for
|
||||
"primary key".
|
||||
|
|
@ -692,8 +691,8 @@ equivalent::
|
|||
>>> Entry.objects.filter(blog__id=3) # __exact is implied
|
||||
>>> Entry.objects.filter(blog__pk=3) # __pk implies __id__exact
|
||||
|
||||
Escaping percent signs and underscores in LIKE statements
|
||||
---------------------------------------------------------
|
||||
Escaping percent signs and underscores in ``LIKE`` statements
|
||||
-------------------------------------------------------------
|
||||
|
||||
The field lookups that equate to ``LIKE`` SQL statements (``iexact``,
|
||||
``contains``, ``icontains``, ``startswith``, ``istartswith``, ``endswith``
|
||||
|
|
@ -720,8 +719,8 @@ for you transparently.
|
|||
|
||||
.. _caching-and-querysets:
|
||||
|
||||
Caching and QuerySets
|
||||
---------------------
|
||||
Caching and ``QuerySet``\s
|
||||
--------------------------
|
||||
|
||||
Each :class:`~django.db.models.query.QuerySet` contains a cache to minimize
|
||||
database access. Understanding how it works will allow you to write the most
|
||||
|
|
@ -756,8 +755,8 @@ To avoid this problem, simply save the
|
|||
>>> print([p.headline for p in queryset]) # Evaluate the query set.
|
||||
>>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.
|
||||
|
||||
When querysets are not cached
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
When ``QuerySet``\s are not cached
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Querysets do not always cache their results. When evaluating only *part* of
|
||||
the queryset, the cache is checked, but if it is not populated then the items
|
||||
|
|
@ -795,8 +794,8 @@ being evaluated and therefore populate the cache::
|
|||
|
||||
.. _complex-lookups-with-q:
|
||||
|
||||
Complex lookups with Q objects
|
||||
==============================
|
||||
Complex lookups with ``Q`` objects
|
||||
==================================
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -35,8 +35,8 @@ a secure connection is used.
|
|||
The character set of email sent with ``django.core.mail`` will be set to
|
||||
the value of your :setting:`DEFAULT_CHARSET` setting.
|
||||
|
||||
send_mail()
|
||||
===========
|
||||
``send_mail()``
|
||||
===============
|
||||
|
||||
.. function:: send_mail(subject, message, from_email, recipient_list, fail_silently=False, auth_user=None, auth_password=None, connection=None, html_message=None)
|
||||
|
||||
|
|
@ -74,8 +74,8 @@ are required.
|
|||
The return value will be the number of successfully delivered messages (which
|
||||
can be ``0`` or ``1`` since it can only send one message).
|
||||
|
||||
send_mass_mail()
|
||||
================
|
||||
``send_mass_mail()``
|
||||
====================
|
||||
|
||||
.. function:: send_mass_mail(datatuple, fail_silently=False, auth_user=None, auth_password=None, connection=None)
|
||||
|
||||
|
|
@ -103,8 +103,8 @@ mail server would be opened::
|
|||
|
||||
The return value will be the number of successfully delivered messages.
|
||||
|
||||
send_mass_mail() vs. send_mail()
|
||||
--------------------------------
|
||||
``send_mass_mail()`` vs. ``send_mail()``
|
||||
----------------------------------------
|
||||
|
||||
The main difference between :meth:`~django.core.mail.send_mass_mail()` and
|
||||
:meth:`~django.core.mail.send_mail()` is that
|
||||
|
|
@ -113,8 +113,8 @@ each time it's executed, while :meth:`~django.core.mail.send_mass_mail()` uses
|
|||
a single connection for all of its messages. This makes
|
||||
:meth:`~django.core.mail.send_mass_mail()` slightly more efficient.
|
||||
|
||||
mail_admins()
|
||||
=============
|
||||
``mail_admins()``
|
||||
=================
|
||||
|
||||
.. function:: mail_admins(subject, message, fail_silently=False, connection=None, html_message=None)
|
||||
|
||||
|
|
@ -134,8 +134,8 @@ If ``html_message`` is provided, the resulting email will be a
|
|||
:mimetype:`text/plain` content type and ``html_message`` as the
|
||||
:mimetype:`text/html` content type.
|
||||
|
||||
mail_managers()
|
||||
===============
|
||||
``mail_managers()``
|
||||
===================
|
||||
|
||||
.. function:: mail_managers(subject, message, fail_silently=False, connection=None, html_message=None)
|
||||
|
||||
|
|
@ -205,8 +205,8 @@ from the request's POST data, sends that to admin@example.com and redirects to
|
|||
|
||||
.. _emailmessage-and-smtpconnection:
|
||||
|
||||
The EmailMessage class
|
||||
======================
|
||||
The ``EmailMessage`` class
|
||||
==========================
|
||||
|
||||
Django's :meth:`~django.core.mail.send_mail()` and
|
||||
:meth:`~django.core.mail.send_mass_mail()` functions are actually thin
|
||||
|
|
@ -235,8 +235,8 @@ For convenience, :class:`~django.core.mail.EmailMessage` provides a simple
|
|||
messages, the email backend API :ref:`provides an alternative
|
||||
<topics-sending-multiple-emails>`.
|
||||
|
||||
EmailMessage Objects
|
||||
--------------------
|
||||
``EmailMessage`` Objects
|
||||
------------------------
|
||||
|
||||
.. class:: EmailMessage
|
||||
|
||||
|
|
|
|||
|
|
@ -193,8 +193,8 @@ sent without any data)::
|
|||
|
||||
.. _understanding-the-managementform:
|
||||
|
||||
Understanding the ManagementForm
|
||||
--------------------------------
|
||||
Understanding the ``ManagementForm``
|
||||
------------------------------------
|
||||
|
||||
You may have noticed the additional data (``form-TOTAL_FORMS``,
|
||||
``form-INITIAL_FORMS`` and ``form-MAX_NUM_FORMS``) that was required
|
||||
|
|
|
|||
|
|
@ -793,8 +793,8 @@ instances of the model, you can specify an empty QuerySet::
|
|||
|
||||
>>> AuthorFormSet(queryset=Author.objects.none())
|
||||
|
||||
Changing the ``form``
|
||||
---------------------
|
||||
Changing the form
|
||||
-----------------
|
||||
|
||||
By default, when you use ``modelformset_factory``, a model form will
|
||||
be created using :func:`~django.forms.models.modelform_factory`.
|
||||
|
|
|
|||
|
|
@ -85,8 +85,8 @@ Python class that defines one or more of the following methods:
|
|||
|
||||
.. _request-middleware:
|
||||
|
||||
``process_request``
|
||||
-------------------
|
||||
``process_request()``
|
||||
---------------------
|
||||
|
||||
.. method:: process_request(request)
|
||||
|
||||
|
|
@ -106,8 +106,8 @@ return the result.
|
|||
|
||||
.. _view-middleware:
|
||||
|
||||
``process_view``
|
||||
----------------
|
||||
``process_view()``
|
||||
------------------
|
||||
|
||||
.. method:: process_view(request, view_func, view_args, view_kwargs)
|
||||
|
||||
|
|
@ -145,8 +145,8 @@ view; it'll apply response middleware to that
|
|||
|
||||
.. _template-response-middleware:
|
||||
|
||||
``process_template_response``
|
||||
-----------------------------
|
||||
``process_template_response()``
|
||||
-------------------------------
|
||||
|
||||
.. method:: process_template_response(request, response)
|
||||
|
||||
|
|
@ -172,8 +172,8 @@ includes ``process_template_response()``.
|
|||
|
||||
.. _response-middleware:
|
||||
|
||||
``process_response``
|
||||
--------------------
|
||||
``process_response()``
|
||||
----------------------
|
||||
|
||||
.. method:: process_response(request, response)
|
||||
|
||||
|
|
@ -229,8 +229,8 @@ must test for streaming responses and adjust their behavior accordingly::
|
|||
|
||||
.. _exception-middleware:
|
||||
|
||||
``process_exception``
|
||||
---------------------
|
||||
``process_exception()``
|
||||
-----------------------
|
||||
|
||||
.. method:: process_exception(request, exception)
|
||||
|
||||
|
|
@ -248,8 +248,8 @@ Again, middleware are run in reverse order during the response phase, which
|
|||
includes ``process_exception``. If an exception middleware returns a response,
|
||||
the middleware classes above that middleware will not be called at all.
|
||||
|
||||
``__init__``
|
||||
------------
|
||||
``__init__()``
|
||||
--------------
|
||||
|
||||
Most middleware classes won't need an initializer since middleware classes are
|
||||
essentially placeholders for the ``process_*`` methods. If you do need some
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ easily available on the internet. Although the cookie session storage signs the
|
|||
cookie-stored data to prevent tampering, a :setting:`SECRET_KEY` leak
|
||||
immediately escalates to a remote code execution vulnerability.
|
||||
|
||||
Bundled Serializers
|
||||
Bundled serializers
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. class:: serializers.JSONSerializer
|
||||
|
|
@ -359,7 +359,7 @@ Bundled Serializers
|
|||
|
||||
.. _custom-serializers:
|
||||
|
||||
Write Your Own Serializer
|
||||
Write your own serializer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note that unlike :class:`~django.contrib.sessions.serializers.PickleSerializer`,
|
||||
|
|
|
|||
|
|
@ -12,8 +12,8 @@ The package ``django.shortcuts`` collects helper functions and classes that
|
|||
"span" multiple levels of MVC. In other words, these functions/classes
|
||||
introduce controlled coupling for convenience's sake.
|
||||
|
||||
``render``
|
||||
==========
|
||||
``render()``
|
||||
============
|
||||
|
||||
.. function:: render(request, template_name, context=None, content_type=None, status=None, using=None)
|
||||
|
||||
|
|
@ -81,8 +81,8 @@ This example is equivalent to::
|
|||
return HttpResponse(t.render(c, request),
|
||||
content_type="application/xhtml+xml")
|
||||
|
||||
``render_to_response``
|
||||
======================
|
||||
``render_to_response()``
|
||||
========================
|
||||
|
||||
.. function:: render_to_response(template_name, context=None, content_type=None, status=None, using=None)
|
||||
|
||||
|
|
@ -90,8 +90,8 @@ This example is equivalent to::
|
|||
similarly except that it doesn't make the ``request`` available in the
|
||||
response. It's not recommended and is likely to be deprecated in the future.
|
||||
|
||||
``redirect``
|
||||
============
|
||||
``redirect()``
|
||||
==============
|
||||
|
||||
.. function:: redirect(to, permanent=False, *args, **kwargs)
|
||||
|
||||
|
|
@ -157,8 +157,8 @@ will be returned::
|
|||
object = MyModel.objects.get(...)
|
||||
return redirect(object, permanent=True)
|
||||
|
||||
``get_object_or_404``
|
||||
=====================
|
||||
``get_object_or_404()``
|
||||
=======================
|
||||
|
||||
.. function:: get_object_or_404(klass, *args, **kwargs)
|
||||
|
||||
|
|
@ -230,8 +230,8 @@ Note: As with ``get()``, a
|
|||
:class:`~django.core.exceptions.MultipleObjectsReturned` exception
|
||||
will be raised if more than one object is found.
|
||||
|
||||
``get_list_or_404``
|
||||
===================
|
||||
``get_list_or_404()``
|
||||
=====================
|
||||
|
||||
.. function:: get_list_or_404(klass, *args, **kwargs)
|
||||
|
||||
|
|
|
|||
|
|
@ -234,8 +234,8 @@ Performance
|
|||
Each regular expression in a ``urlpatterns`` is compiled the first time it's
|
||||
accessed. This makes the system blazingly fast.
|
||||
|
||||
Syntax of the urlpatterns variable
|
||||
==================================
|
||||
Syntax of the ``urlpatterns`` variable
|
||||
======================================
|
||||
|
||||
``urlpatterns`` should be a Python list of :func:`~django.conf.urls.url`
|
||||
instances.
|
||||
|
|
|
|||
|
|
@ -94,8 +94,8 @@ to create a return class for any status code you like. For example::
|
|||
Because 404 errors are by far the most common HTTP error, there's an easier way
|
||||
to handle those errors.
|
||||
|
||||
The Http404 exception
|
||||
---------------------
|
||||
The ``Http404`` exception
|
||||
-------------------------
|
||||
|
||||
.. class:: django.http.Http404()
|
||||
|
||||
|
|
|
|||
|
|
@ -76,8 +76,8 @@ Template tags
|
|||
|
||||
.. templatetag:: localize
|
||||
|
||||
localize
|
||||
~~~~~~~~
|
||||
``localize``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Enables or disables localization of template variables in the
|
||||
contained block.
|
||||
|
|
@ -110,8 +110,8 @@ Template filters
|
|||
|
||||
.. templatefilter:: localize
|
||||
|
||||
localize
|
||||
~~~~~~~~
|
||||
``localize``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Forces localization of a single value.
|
||||
|
||||
|
|
@ -125,11 +125,10 @@ To disable localization on a single value, use :tfilter:`unlocalize`. To control
|
|||
localization over a large section of a template, use the :ttag:`localize` template
|
||||
tag.
|
||||
|
||||
|
||||
.. templatefilter:: unlocalize
|
||||
|
||||
unlocalize
|
||||
~~~~~~~~~~
|
||||
``unlocalize``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Forces a single value to be printed without localization.
|
||||
|
||||
|
|
|
|||
|
|
@ -257,8 +257,8 @@ Template tags
|
|||
|
||||
.. templatetag:: localtime
|
||||
|
||||
localtime
|
||||
~~~~~~~~~
|
||||
``localtime``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Enables or disables conversion of aware datetime objects to the current time
|
||||
zone in the contained block.
|
||||
|
|
@ -286,8 +286,8 @@ To activate or deactivate conversion for a template block, use::
|
|||
|
||||
.. templatetag:: timezone
|
||||
|
||||
timezone
|
||||
~~~~~~~~
|
||||
``timezone``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Sets or unsets the current time zone in the contained block. When the current
|
||||
time zone is unset, the default time zone applies.
|
||||
|
|
@ -306,8 +306,8 @@ time zone is unset, the default time zone applies.
|
|||
|
||||
.. templatetag:: get_current_timezone
|
||||
|
||||
get_current_timezone
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
``get_current_timezone``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can get the name of the current time zone using the
|
||||
``get_current_timezone`` tag::
|
||||
|
|
@ -327,8 +327,8 @@ return aware datetimes.
|
|||
|
||||
.. templatefilter:: localtime
|
||||
|
||||
localtime
|
||||
~~~~~~~~~
|
||||
``localtime``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Forces conversion of a single value to the current time zone.
|
||||
|
||||
|
|
@ -340,8 +340,8 @@ For example::
|
|||
|
||||
.. templatefilter:: utc
|
||||
|
||||
utc
|
||||
~~~
|
||||
``utc``
|
||||
~~~~~~~
|
||||
|
||||
Forces conversion of a single value to UTC.
|
||||
|
||||
|
|
@ -353,8 +353,8 @@ For example::
|
|||
|
||||
.. templatefilter:: timezone
|
||||
|
||||
timezone
|
||||
~~~~~~~~
|
||||
``timezone``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Forces conversion of a single value to an arbitrary timezone.
|
||||
|
||||
|
|
|
|||
|
|
@ -477,8 +477,8 @@ directly with the ``number`` argument::
|
|||
raise forms.ValidationError(self.error_message % number)
|
||||
|
||||
|
||||
Joining strings: string_concat()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Joining strings: ``string_concat()``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Standard Python string joins (``''.join([...])``) will not work on lists
|
||||
containing lazy translation objects. Instead, you can use
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ your operating system's package manager.
|
|||
If you are just starting with Django and using Windows, you may find
|
||||
:doc:`/howto/windows` useful.
|
||||
|
||||
Install Apache and mod_wsgi
|
||||
=============================
|
||||
Install Apache and ``mod_wsgi``
|
||||
===============================
|
||||
|
||||
If you just want to experiment with Django, skip ahead to the next
|
||||
section; Django includes a lightweight web server you can use for
|
||||
|
|
|
|||
|
|
@ -692,8 +692,8 @@ the main module body, rather than the class body.
|
|||
|
||||
.. _custom-deconstruct-method:
|
||||
|
||||
Adding a deconstruct() method
|
||||
-----------------------------
|
||||
Adding a ``deconstruct()`` method
|
||||
---------------------------------
|
||||
|
||||
You can let Django serialize your own custom class instances by giving the class
|
||||
a ``deconstruct()`` method. It takes no arguments, and should return a tuple
|
||||
|
|
|
|||
|
|
@ -232,8 +232,8 @@ until it's strictly required.
|
|||
Databases
|
||||
=========
|
||||
|
||||
:doc:`Database optimization </topics/db/optimization>`
|
||||
------------------------------------------------------
|
||||
Database optimization
|
||||
---------------------
|
||||
|
||||
Django’s database layer provides various ways to help developers get the best
|
||||
performance from their databases. The :doc:`database optimization documentation
|
||||
|
|
|
|||
|
|
@ -131,8 +131,8 @@ and ``SafeText`` respectively.
|
|||
|
||||
For forwards compatibility, the new names work as of Django 1.4.2.
|
||||
|
||||
:meth:`~object.__str__` and ` __unicode__()`_ methods
|
||||
-----------------------------------------------------
|
||||
``__str__()`` and ``__unicode__()`` methods
|
||||
-------------------------------------------
|
||||
|
||||
In Python 2, the object model specifies :meth:`~object.__str__` and
|
||||
` __unicode__()`_ methods. If these methods exist, they must return
|
||||
|
|
@ -370,8 +370,8 @@ Some modules were renamed in Python 3. The ``django.utils.six.moves``
|
|||
module (based on the :mod:`six.moves module <six.moves>`) provides a
|
||||
compatible location to import them.
|
||||
|
||||
PY2
|
||||
~~~
|
||||
``PY2``
|
||||
~~~~~~~
|
||||
|
||||
If you need different code in Python 2 and Python 3, check :data:`six.PY2`::
|
||||
|
||||
|
|
@ -383,8 +383,8 @@ function.
|
|||
|
||||
.. module:: django.utils.six
|
||||
|
||||
Django customized version of six
|
||||
--------------------------------
|
||||
Django customized version of ``six``
|
||||
------------------------------------
|
||||
|
||||
The version of six bundled with Django (``django.utils.six``) includes a few
|
||||
customizations for internal use only.
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ be serialized.
|
|||
serialized object doesn't specify all the fields that are required by a
|
||||
model, the deserializer will not be able to save deserialized instances.
|
||||
|
||||
Inherited Models
|
||||
Inherited models
|
||||
----------------
|
||||
|
||||
If you have a model that is defined using an :ref:`abstract base class
|
||||
|
|
|
|||
|
|
@ -48,8 +48,8 @@ Python `import search path`_.
|
|||
|
||||
.. _import search path: http://www.diveintopython.net/getting_to_know_python/everything_is_an_object.html
|
||||
|
||||
The django-admin utility
|
||||
---------------------------
|
||||
The ``django-admin`` utility
|
||||
----------------------------
|
||||
|
||||
When using :doc:`django-admin </ref/django-admin>`, you can either set the
|
||||
environment variable once, or explicitly pass in the settings module each time
|
||||
|
|
@ -71,8 +71,8 @@ Use the ``--settings`` command-line argument to specify the settings manually::
|
|||
|
||||
.. _django-admin: ../django-admin/
|
||||
|
||||
On the server (mod_wsgi)
|
||||
--------------------------
|
||||
On the server (``mod_wsgi``)
|
||||
----------------------------
|
||||
|
||||
In your live server environment, you'll need to tell your WSGI
|
||||
application what settings file to use. Do that with ``os.environ``::
|
||||
|
|
@ -171,8 +171,8 @@ a convention.
|
|||
|
||||
.. _settings-without-django-settings-module:
|
||||
|
||||
Using settings without setting DJANGO_SETTINGS_MODULE
|
||||
=====================================================
|
||||
Using settings without setting ``DJANGO_SETTINGS_MODULE``
|
||||
=========================================================
|
||||
|
||||
In some cases, you might want to bypass the ``DJANGO_SETTINGS_MODULE``
|
||||
environment variable. For example, if you're using the template system by
|
||||
|
|
@ -235,8 +235,8 @@ defaults, so you must specify a value for every possible setting that might be
|
|||
used in that code you are importing. Check in
|
||||
``django.conf.settings.global_settings`` for the full list.
|
||||
|
||||
Either configure() or DJANGO_SETTINGS_MODULE is required
|
||||
--------------------------------------------------------
|
||||
Either ``configure()`` or ``DJANGO_SETTINGS_MODULE`` is required
|
||||
----------------------------------------------------------------
|
||||
|
||||
If you're not setting the ``DJANGO_SETTINGS_MODULE`` environment variable, you
|
||||
*must* call ``configure()`` at some point before using any code that reads
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ You may also find signing useful for the following:
|
|||
protected resource, for example a downloadable file that a user has
|
||||
paid for.
|
||||
|
||||
Protecting the SECRET_KEY
|
||||
=========================
|
||||
Protecting the ``SECRET_KEY``
|
||||
=============================
|
||||
|
||||
When you create a new Django project using :djadmin:`startproject`, the
|
||||
``settings.py`` file is generated automatically and gets a random
|
||||
|
|
@ -79,8 +79,8 @@ generate signatures. You can use a different secret by passing it to the
|
|||
<https://tools.ietf.org/html/rfc4648#section-5>`_. This alphabet contains
|
||||
alphanumeric characters, hyphens, and underscores.
|
||||
|
||||
Using the salt argument
|
||||
-----------------------
|
||||
Using the ``salt`` argument
|
||||
---------------------------
|
||||
|
||||
If you do not wish for every occurrence of a particular string to have the same
|
||||
signature hash, you can use the optional ``salt`` argument to the ``Signer``
|
||||
|
|
|
|||
|
|
@ -534,8 +534,8 @@ Methods
|
|||
Testing utilities
|
||||
-----------------
|
||||
|
||||
django.test.utils
|
||||
~~~~~~~~~~~~~~~~~
|
||||
``django.test.utils``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. module:: django.test.utils
|
||||
:synopsis: Helpers to write custom test runners.
|
||||
|
|
@ -555,8 +555,8 @@ utility methods in the ``django.test.utils`` module.
|
|||
magic hooks into the template system and restoring normal email
|
||||
services.
|
||||
|
||||
django.db.connection.creation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
``django.db.connection.creation``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. currentmodule:: django.db.connection.creation
|
||||
|
||||
|
|
@ -615,8 +615,8 @@ can be useful during testing.
|
|||
|
||||
.. _topics-testing-code-coverage:
|
||||
|
||||
Integration with coverage.py
|
||||
============================
|
||||
Integration with ``coverage.py``
|
||||
================================
|
||||
|
||||
Code coverage describes how much source code has been tested. It shows which
|
||||
parts of your code are being exercised by tests and which are not. It's an
|
||||
|
|
|
|||
|
|
@ -617,8 +617,8 @@ Normal Python unit test classes extend a base class of
|
|||
|
||||
Hierarchy of Django unit testing classes
|
||||
|
||||
SimpleTestCase
|
||||
--------------
|
||||
``SimpleTestCase``
|
||||
------------------
|
||||
|
||||
.. class:: SimpleTestCase()
|
||||
|
||||
|
|
@ -701,8 +701,8 @@ then you should use :class:`~django.test.TransactionTestCase` or
|
|||
:exc:`unittest.SkipTest` in ``setUpClass()``, be sure to do it before
|
||||
calling ``super()`` to avoid this.
|
||||
|
||||
TransactionTestCase
|
||||
-------------------
|
||||
``TransactionTestCase``
|
||||
-----------------------
|
||||
|
||||
.. class:: TransactionTestCase()
|
||||
|
||||
|
|
@ -742,8 +742,8 @@ to test the effects of commit and rollback:
|
|||
|
||||
``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
|
||||
|
||||
TestCase
|
||||
--------
|
||||
``TestCase``
|
||||
------------
|
||||
|
||||
.. class:: TestCase()
|
||||
|
||||
|
|
@ -811,8 +811,8 @@ additions, including:
|
|||
|
||||
.. _live-test-server:
|
||||
|
||||
LiveServerTestCase
|
||||
------------------
|
||||
``LiveServerTestCase``
|
||||
----------------------
|
||||
|
||||
.. class:: LiveServerTestCase()
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue