Fixed #25755 -- Unified spelling of "website".
This commit is contained in:
parent
53326e2c8a
commit
1f8dad6915
|
@ -13,7 +13,7 @@ At the same time, the World Online Web developers have consistently been
|
|||
perfectionists when it comes to following best practices of Web development.
|
||||
|
||||
In fall 2003, the World Online developers (Adrian Holovaty and Simon Willison)
|
||||
ditched PHP and began using Python to develop its Web sites. As they built
|
||||
ditched PHP and began using Python to develop its websites. As they built
|
||||
intensive, richly interactive sites such as Lawrence.com, they began to extract
|
||||
a generic Web development framework that let them build Web applications more
|
||||
and more quickly. They tweaked this framework constantly, adding improvements
|
||||
|
@ -148,7 +148,7 @@ Is Django a content-management-system (CMS)?
|
|||
--------------------------------------------
|
||||
|
||||
No, Django is not a CMS, or any sort of "turnkey product" in and of itself.
|
||||
It's a Web framework; it's a programming tool that lets you build Web sites.
|
||||
It's a Web framework; it's a programming tool that lets you build websites.
|
||||
|
||||
For example, it doesn't make much sense to compare Django to something like
|
||||
Drupal_, because Django is something you use to *create* things like Drupal.
|
||||
|
|
|
@ -10,7 +10,7 @@ This document will get you up and running with Django on top of Jython.
|
|||
Installing Jython
|
||||
=================
|
||||
|
||||
Django works with Jython versions 2.7b2 and higher. See the Jython_ Web site for
|
||||
Django works with Jython versions 2.7b2 and higher. See the Jython_ website for
|
||||
download and installation instructions.
|
||||
|
||||
.. _jython: http://www.jython.org/
|
||||
|
@ -48,7 +48,7 @@ on top of Jython.
|
|||
.. _`django-jython`: https://github.com/beachmachine/django-jython
|
||||
|
||||
To install it, follow the `installation instructions`_ detailed on the project
|
||||
Web site. Also, read the `database backends`_ documentation there.
|
||||
website. Also, read the `database backends`_ documentation there.
|
||||
|
||||
.. _`installation instructions`: https://pythonhosted.org/django-jython/quickstart.html#install
|
||||
.. _`database backends`: https://pythonhosted.org/django-jython/database-backends.html
|
||||
|
|
|
@ -70,7 +70,7 @@ pull request "Merged in XXXXXXX" (replacing with the commit hash) after you
|
|||
merge it. Trac checks for this message format to indicate on the ticket page
|
||||
whether or not a pull request is merged.
|
||||
|
||||
Avoid using GitHub's "Merge pull request" button on the Web site as its creates
|
||||
Avoid using GitHub's "Merge pull request" button on the website as it creates
|
||||
an ugly "merge commit" and makes navigating history more difficult.
|
||||
|
||||
When rewriting the commit history of a pull request, the goal is to make
|
||||
|
|
|
@ -106,7 +106,7 @@ documentation:
|
|||
* **Web**, **World Wide Web**, **the Web** -- note Web is always
|
||||
capitalized when referring to the World Wide Web.
|
||||
|
||||
* **Web site** -- use two words, with Web capitalized.
|
||||
* **website** -- use one word, without capitalization.
|
||||
|
||||
Django-specific terminology
|
||||
---------------------------
|
||||
|
|
|
@ -22,7 +22,7 @@ over time, so you'll need a copy of the Git client (a program called ``git``)
|
|||
on your computer, and you'll want to familiarize yourself with the basics of
|
||||
how Git works.
|
||||
|
||||
Git's web site offers downloads for various operating systems. The site also
|
||||
Git's website offers downloads for various operating systems. The site also
|
||||
contains vast amounts of `documentation`_.
|
||||
|
||||
The Django Git repository is located online at `github.com/django/django
|
||||
|
|
|
@ -142,7 +142,7 @@ A dynamic admin interface: it's not just scaffolding -- it's the whole house
|
|||
|
||||
Once your models are defined, Django can automatically create a professional,
|
||||
production ready :doc:`administrative interface </ref/contrib/admin/index>` --
|
||||
a Web site that lets authenticated users add, change and delete objects. It's
|
||||
a website that lets authenticated users add, change and delete objects. It's
|
||||
as easy as registering your model in the admin site:
|
||||
|
||||
.. snippet::
|
||||
|
|
|
@ -300,7 +300,7 @@ the world! If this wasn't just an example, you could now:
|
|||
|
||||
* Email the package to a friend.
|
||||
|
||||
* Upload the package on your Web site.
|
||||
* Upload the package on your website.
|
||||
|
||||
* Post the package on a public repository, such as `the Python Package Index
|
||||
(PyPI)`_. `packaging.python.org <https://packaging.python.org>`_ has `a good
|
||||
|
|
|
@ -208,7 +208,7 @@ rather than creating directories.
|
|||
What's the difference between a project and an app? An app is a Web
|
||||
application that does something -- e.g., a Weblog system, a database of
|
||||
public records or a simple poll app. A project is a collection of
|
||||
configuration and apps for a particular Web site. A project can contain
|
||||
configuration and apps for a particular website. A project can contain
|
||||
multiple apps. An app can be in multiple projects.
|
||||
|
||||
Your apps can live anywhere on your `Python path`_. In this tutorial, we'll
|
||||
|
|
|
@ -103,7 +103,7 @@ method and display whatever ID you provide in the URL. Try
|
|||
"/polls/34/results/" and "/polls/34/vote/" too -- these will display the
|
||||
placeholder results and voting pages.
|
||||
|
||||
When somebody requests a page from your Web site -- say, "/polls/34/", Django
|
||||
When somebody requests a page from your website -- say, "/polls/34/", Django
|
||||
will load the ``mysite.urls`` Python module because it's pointed to by the
|
||||
:setting:`ROOT_URLCONF` setting. It finds the variable named ``urlpatterns``
|
||||
and traverses the regular expressions in order. The
|
||||
|
|
|
@ -183,7 +183,7 @@ without having chosen a choice, you should see the error message.
|
|||
The code for our ``vote()`` view does have a small problem. It first gets
|
||||
the ``selected_choice`` object from the database, then computes the new
|
||||
value of ``votes``, and then saves it back to the database. If two users of
|
||||
your Web site try to vote at *exactly the same time*, this might go wrong:
|
||||
your website try to vote at *exactly the same time*, this might go wrong:
|
||||
The same value, let's say 42, will be retrieved for ``votes``. Then, for
|
||||
both users the new value of 43 is computed and saved, but 44 would be the
|
||||
expected value.
|
||||
|
|
|
@ -161,7 +161,7 @@ You can get a local copy of the HTML documentation following a few easy steps:
|
|||
|
||||
* Django's documentation uses a system called Sphinx__ to convert from
|
||||
plain text to HTML. You'll need to install Sphinx by either downloading
|
||||
and installing the package from the Sphinx Web site, or with ``pip``:
|
||||
and installing the package from the Sphinx website, or with ``pip``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
@ -206,7 +206,7 @@ support functionality that goes beyond this basic goal.
|
|||
Discourage redundancy
|
||||
---------------------
|
||||
|
||||
The majority of dynamic Web sites use some sort of common sitewide design --
|
||||
The majority of dynamic websites use some sort of common sitewide design --
|
||||
a common header, footer, navigation bar, etc. The Django template system should
|
||||
make it easy to store those elements in a single place, eliminating duplicate
|
||||
code.
|
||||
|
|
|
@ -2702,7 +2702,7 @@ Multiple admin sites in the same URLconf
|
|||
----------------------------------------
|
||||
|
||||
It's easy to create multiple instances of the admin site on the same
|
||||
Django-powered Web site. Just create multiple instances of ``AdminSite`` and
|
||||
Django-powered website. Just create multiple instances of ``AdminSite`` and
|
||||
root each one at a different URL.
|
||||
|
||||
In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature
|
||||
|
|
|
@ -153,7 +153,7 @@ Widget classes
|
|||
``template_name`` is ``gis/openlayers.html``.
|
||||
|
||||
``OpenLayersWidget`` and :class:`OSMWidget` use the ``openlayers.js`` file
|
||||
hosted on the ``openlayers.org`` Web site. This works for basic usage
|
||||
hosted on the ``openlayers.org`` website. This works for basic usage
|
||||
during development, but isn't appropriate for a production deployment as
|
||||
``openlayers.org/api/`` has no guaranteed uptime and runs on a slow server.
|
||||
You are therefore advised to subclass these widgets in order to specify
|
||||
|
|
|
@ -104,7 +104,7 @@ internal geometry representation used by GeoDjango (it's behind the "lazy"
|
|||
geometries). Specifically, the C API library is called (e.g., ``libgeos_c.so``)
|
||||
directly from Python using ctypes.
|
||||
|
||||
First, download GEOS 3.4.2 from the GEOS Web site and untar the source
|
||||
First, download GEOS 3.4.2 from the GEOS website and untar the source
|
||||
archive::
|
||||
|
||||
$ wget http://download.osgeo.org/geos/geos-3.4.2.tar.bz2
|
||||
|
|
|
@ -381,7 +381,7 @@ GeoDjango on Windows.
|
|||
Python
|
||||
^^^^^^
|
||||
|
||||
First, download the latest `Python 2.7 installer`__ from the Python Web site.
|
||||
First, download the latest `Python 2.7 installer`__ from the Python website.
|
||||
Next, run the installer and keep the defaults -- for example, keep
|
||||
'Install for all users' checked and the installation path set as
|
||||
``C:\Python27``.
|
||||
|
@ -398,7 +398,7 @@ PostgreSQL
|
|||
^^^^^^^^^^
|
||||
|
||||
First, download the latest `PostgreSQL 9.x installer`__ from the
|
||||
`EnterpriseDB`__ Web site. After downloading, simply run the installer,
|
||||
`EnterpriseDB`__ website. After downloading, simply run the installer,
|
||||
follow the on-screen directions, and keep the default options unless
|
||||
you know the consequences of changing them.
|
||||
|
||||
|
|
|
@ -147,7 +147,7 @@ Additional Resources:
|
|||
|
||||
* `spatialreference.org`__: A Django-powered database of spatial reference
|
||||
systems.
|
||||
* `The State Plane Coordinate System`__: A Web site covering the various
|
||||
* `The State Plane Coordinate System`__: A website covering the various
|
||||
projection systems used in the United States. Much of the U.S. spatial
|
||||
data encountered will be in one of these coordinate systems rather than
|
||||
in a geographic coordinate system such as WGS84.
|
||||
|
|
|
@ -116,7 +116,7 @@ See the :doc:`sessions documentation </topics/http/sessions>`.
|
|||
sites
|
||||
=====
|
||||
|
||||
A light framework that lets you operate multiple Web sites off of the same
|
||||
A light framework that lets you operate multiple websites off of the same
|
||||
database and Django installation. It gives you hooks for associating objects to
|
||||
one or more sites.
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ creating sitemap_ XML files easy.
|
|||
Overview
|
||||
========
|
||||
|
||||
A sitemap is an XML file on your Web site that tells search-engine indexers how
|
||||
A sitemap is an XML file on your website that tells search-engine indexers how
|
||||
frequently your pages change and how "important" certain pages are in relation
|
||||
to other pages on your site. This information helps search engines index your
|
||||
site.
|
||||
|
|
|
@ -3,11 +3,11 @@ The "sites" framework
|
|||
=====================
|
||||
|
||||
.. module:: django.contrib.sites
|
||||
:synopsis: Lets you operate multiple Web sites from the same database and
|
||||
:synopsis: Lets you operate multiple websites from the same database and
|
||||
Django project
|
||||
|
||||
Django comes with an optional "sites" framework. It's a hook for associating
|
||||
objects and functionality to particular Web sites, and it's a holding place for
|
||||
objects and functionality to particular websites, and it's a holding place for
|
||||
the domain names and "verbose" names of your Django-powered sites.
|
||||
|
||||
Use it if your single Django installation powers more than one site and you
|
||||
|
@ -17,11 +17,11 @@ The sites framework is mainly based on a simple model:
|
|||
|
||||
.. class:: models.Site
|
||||
|
||||
A model for storing the ``domain`` and ``name`` attributes of a Web site.
|
||||
A model for storing the ``domain`` and ``name`` attributes of a website.
|
||||
|
||||
.. attribute:: domain
|
||||
|
||||
The fully qualified domain name associated with the Web site.
|
||||
The fully qualified domain name associated with the website.
|
||||
For example, ``www.example.com``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
@ -31,7 +31,7 @@ The sites framework is mainly based on a simple model:
|
|||
|
||||
.. attribute:: name
|
||||
|
||||
A human-readable "verbose" name for the Web site.
|
||||
A human-readable "verbose" name for the website.
|
||||
|
||||
The :setting:`SITE_ID` setting specifies the database ID of the
|
||||
:class:`~django.contrib.sites.models.Site` object associated with that
|
||||
|
|
|
@ -7,8 +7,8 @@ Cross Site Request Forgery protection
|
|||
|
||||
The CSRF middleware and template tag provides easy-to-use protection against
|
||||
`Cross Site Request Forgeries`_. This type of attack occurs when a malicious
|
||||
Web site contains a link, a form button or some JavaScript that is intended to
|
||||
perform some action on your Web site, using the credentials of a logged-in user
|
||||
website contains a link, a form button or some JavaScript that is intended to
|
||||
perform some action on your website, using the credentials of a logged-in user
|
||||
who visits the malicious site in their browser. A related type of attack,
|
||||
'login CSRF', where an attacking site tricks a user's browser into logging into
|
||||
a site with someone else's credentials, is also covered.
|
||||
|
|
|
@ -111,12 +111,12 @@ We've specified ``auto_id=False`` to simplify the output::
|
|||
>>> from django import forms
|
||||
>>> class CommentForm(forms.Form):
|
||||
... name = forms.CharField(label='Your name')
|
||||
... url = forms.URLField(label='Your Web site', required=False)
|
||||
... url = forms.URLField(label='Your website', required=False)
|
||||
... comment = forms.CharField()
|
||||
>>> f = CommentForm(auto_id=False)
|
||||
>>> print(f)
|
||||
<tr><th>Your name:</th><td><input type="text" name="name" /></td></tr>
|
||||
<tr><th>Your Web site:</th><td><input type="url" name="url" /></td></tr>
|
||||
<tr><th>Your website:</th><td><input type="url" name="url" /></td></tr>
|
||||
<tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
|
||||
|
||||
``label_suffix``
|
||||
|
|
|
@ -159,7 +159,7 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
URL/URI scheme list to validate against. If not provided, the default
|
||||
list is ``['http', 'https', 'ftp', 'ftps']``. As a reference, the IANA
|
||||
Web site provides a full list of `valid URI schemes`_.
|
||||
website provides a full list of `valid URI schemes`_.
|
||||
|
||||
.. _valid URI schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
|
||||
|
||||
|
|
|
@ -98,9 +98,9 @@ Problem reports and getting help
|
|||
================================
|
||||
|
||||
Need help resolving a problem with Django? The documentation in the
|
||||
distribution is also available :doc:`online </index>` at the `Django Web
|
||||
site`_. The :doc:`FAQ </faq/index>` document is especially recommended, as it
|
||||
contains a number of issues that come up time and again.
|
||||
distribution is also available :doc:`online </index>` at the `Django website`_.
|
||||
The :doc:`FAQ </faq/index>` document is especially recommended, as it contains
|
||||
a number of issues that come up time and again.
|
||||
|
||||
For more personalized help, the `django-users`_ mailing list is a very active
|
||||
list, with more than 2,000 subscribers who can help you solve any sort of
|
||||
|
@ -113,7 +113,7 @@ there's a #django channel on irc.freenode.net that is regularly populated by
|
|||
Django users and developers from around the world. Friendly people are usually
|
||||
available at any hour of the day -- to help, or just to chat.
|
||||
|
||||
.. _Django Web site: https://www.djangoproject.com/
|
||||
.. _Django website: https://www.djangoproject.com/
|
||||
.. _django-users: http://groups.google.com/group/django-users
|
||||
|
||||
Thanks for using Django!
|
||||
|
|
|
@ -142,8 +142,8 @@ Improved CSRF protection
|
|||
|
||||
Django now has much improved protection against :doc:`Cross-Site Request Forgery
|
||||
(CSRF) attacks</ref/csrf>`. This type of attack occurs when a malicious
|
||||
Web site contains a link, a form button or some JavaScript that is intended to
|
||||
perform some action on your Web site, using the credentials of a logged-in user
|
||||
website contains a link, a form button or some JavaScript that is intended to
|
||||
perform some action on your website, using the credentials of a logged-in user
|
||||
who visits the malicious site in their browser. A related type of attack, "login
|
||||
CSRF," where an attacking site tricks a user's browser into logging into a site
|
||||
with someone else's credentials, is also covered.
|
||||
|
|
|
@ -217,7 +217,7 @@ Authorization for anonymous users
|
|||
|
||||
An anonymous user is one that is not authenticated i.e. they have provided no
|
||||
valid authentication details. However, that does not necessarily mean they are
|
||||
not authorized to do anything. At the most basic level, most Web sites
|
||||
not authorized to do anything. At the most basic level, most websites
|
||||
authorize anonymous users to browse most of the site, and many allow anonymous
|
||||
posting of comments etc.
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
Django's cache framework
|
||||
========================
|
||||
|
||||
A fundamental trade-off in dynamic Web sites is, well, they're dynamic. Each
|
||||
A fundamental trade-off in dynamic websites is, well, they're dynamic. Each
|
||||
time a user requests a page, the Web server makes all sorts of calculations --
|
||||
from database queries to template rendering to business logic -- to create the
|
||||
page that your site's visitor sees. This is a lot more expensive, from a
|
||||
|
@ -1011,7 +1011,7 @@ Downstream caches
|
|||
So far, this document has focused on caching your *own* data. But another type
|
||||
of caching is relevant to Web development, too: caching performed by
|
||||
"downstream" caches. These are systems that cache pages for users even before
|
||||
the request reaches your Web site.
|
||||
the request reaches your website.
|
||||
|
||||
Here are a few examples of downstream caches:
|
||||
|
||||
|
@ -1021,7 +1021,7 @@ Here are a few examples of downstream caches:
|
|||
knowledge of this caching; the ISP sits between example.com and your Web
|
||||
browser, handling all of the caching transparently.
|
||||
|
||||
* Your Django Web site may sit behind a *proxy cache*, such as Squid Web
|
||||
* Your Django website may sit behind a *proxy cache*, such as Squid Web
|
||||
Proxy Cache (http://www.squid-cache.org/), that caches pages for
|
||||
performance. In this case, each request first would be handled by the
|
||||
proxy, and it would be passed to your application only if needed.
|
||||
|
|
|
@ -611,7 +611,7 @@ Configuring email for development
|
|||
=================================
|
||||
|
||||
There are times when you do not want Django to send emails at
|
||||
all. For example, while developing a Web site, you probably don't want
|
||||
all. For example, while developing a website, you probably don't want
|
||||
to send out thousands of emails -- but you may want to validate that
|
||||
emails will be sent to the right people under the right conditions,
|
||||
and that those emails will contain the correct content.
|
||||
|
|
|
@ -11,7 +11,7 @@ Working with forms
|
|||
the forms API, see :doc:`/ref/forms/api`, :doc:`/ref/forms/fields`, and
|
||||
:doc:`/ref/forms/validation`.
|
||||
|
||||
Unless you're planning to build Web sites and applications that do nothing but
|
||||
Unless you're planning to build websites and applications that do nothing but
|
||||
publish content, and don't accept input from your visitors, you're going to
|
||||
need to understand and use forms.
|
||||
|
||||
|
@ -172,7 +172,7 @@ example with:
|
|||
* data received from a previous HTML form submission
|
||||
|
||||
The last of these cases is the most interesting, because it's what makes it
|
||||
possible for users not just to read a Web site, but to send information back
|
||||
possible for users not just to read a website, but to send information back
|
||||
to it too.
|
||||
|
||||
Building a form
|
||||
|
@ -181,7 +181,7 @@ Building a form
|
|||
The work that needs to be done
|
||||
------------------------------
|
||||
|
||||
Suppose you want to create a simple form on your Web site, in order to obtain
|
||||
Suppose you want to create a simple form on your website, in order to obtain
|
||||
the user's name. You'd need something like this in your template:
|
||||
|
||||
.. code-block:: html+django
|
||||
|
@ -269,7 +269,7 @@ We'll have to provide those ourselves in the template.
|
|||
The view
|
||||
^^^^^^^^
|
||||
|
||||
Form data sent back to a Django Web site is processed by a view, generally the
|
||||
Form data sent back to a Django website is processed by a view, generally the
|
||||
same view which published the form. This allows us to reuse some of the same
|
||||
logic.
|
||||
|
||||
|
@ -400,7 +400,7 @@ More on fields
|
|||
--------------
|
||||
|
||||
Consider a more useful form than our minimal example above, which we could use
|
||||
to implement "contact me" functionality on a personal Web site:
|
||||
to implement "contact me" functionality on a personal website:
|
||||
|
||||
.. snippet::
|
||||
:filename: forms.py
|
||||
|
|
|
@ -274,7 +274,7 @@ Including other URLconfs
|
|||
At any point, your ``urlpatterns`` can "include" other URLconf modules. This
|
||||
essentially "roots" a set of URLs below other ones.
|
||||
|
||||
For example, here's an excerpt of the URLconf for the `Django Web site`_
|
||||
For example, here's an excerpt of the URLconf for the `Django website`_
|
||||
itself. It includes a number of other URLconfs::
|
||||
|
||||
from django.conf.urls import include, url
|
||||
|
@ -343,7 +343,7 @@ the suffixes that differ::
|
|||
])),
|
||||
]
|
||||
|
||||
.. _`Django Web site`: https://www.djangoproject.com/
|
||||
.. _`Django website`: https://www.djangoproject.com/
|
||||
|
||||
Captured parameters
|
||||
-------------------
|
||||
|
|
|
@ -16,7 +16,7 @@ translates them to the end user's time zone in templates and forms.
|
|||
This is handy if your users live in more than one time zone and you want to
|
||||
display datetime information according to each user's wall clock.
|
||||
|
||||
Even if your Web site is available in only one time zone, it's still good
|
||||
Even if your website is available in only one time zone, it's still good
|
||||
practice to store data in UTC in your database. The main reason is Daylight
|
||||
Saving Time (DST). Many countries have a system of DST, where clocks are moved
|
||||
forward in spring and backward in autumn. If you're working in local time,
|
||||
|
@ -168,7 +168,7 @@ time zone automatically. Instead, Django provides :ref:`time zone selection
|
|||
functions <time-zone-selection-functions>`. Use them to build the time zone
|
||||
selection logic that makes sense for you.
|
||||
|
||||
Most Web sites that care about time zones just ask users in which time zone they
|
||||
Most websites that care about time zones just ask users in which time zone they
|
||||
live and store this information in the user's profile. For anonymous users,
|
||||
they use the time zone of their primary audience or UTC. pytz_ provides
|
||||
helpers_, like a list of time zones per country, that you can use to pre-select
|
||||
|
|
|
@ -65,7 +65,7 @@ control.
|
|||
|
||||
:ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
|
||||
POST request. This ensures that a malicious user cannot simply "replay" a form
|
||||
POST to your Web site and have another logged in user unwittingly submit that
|
||||
POST to your website and have another logged in user unwittingly submit that
|
||||
form. The malicious user would have to know the nonce, which is user specific
|
||||
(using a cookie).
|
||||
|
||||
|
|
|
@ -740,7 +740,7 @@ TestCase
|
|||
.. class:: TestCase()
|
||||
|
||||
This class provides some additional capabilities that can be useful for testing
|
||||
Web sites.
|
||||
websites.
|
||||
|
||||
Converting a normal :class:`unittest.TestCase` to a Django :class:`TestCase` is
|
||||
easy: Just change the base class of your test from ``'unittest.TestCase'`` to
|
||||
|
@ -1028,7 +1028,7 @@ Fixture loading
|
|||
|
||||
.. attribute:: TransactionTestCase.fixtures
|
||||
|
||||
A test case for a database-backed Web site isn't much use if there isn't any
|
||||
A test case for a database-backed website isn't much use if there isn't any
|
||||
data in the database. To make it easy to put test data into the database,
|
||||
Django's custom ``TransactionTestCase`` class provides a way of loading
|
||||
**fixtures**.
|
||||
|
|
Loading…
Reference in New Issue