Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate.
This commit is contained in:
David Smith
Mariusz Felisiak
parent
acde917456
commit
1024b5e74a
2
AUTHORS
2
AUTHORS
|
|
@ -1,4 +1,4 @@
|
|||
Django was originally created in late 2003 at World Online, the Web division
|
||||
Django was originally created in late 2003 at World Online, the web division
|
||||
of the Lawrence Journal-World newspaper in Lawrence, Kansas.
|
||||
|
||||
Here is an inevitably incomplete list of MUCH-APPRECIATED CONTRIBUTORS --
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Django
|
||||
======
|
||||
|
||||
Django is a high-level Python Web framework that encourages rapid development
|
||||
Django is a high-level Python web framework that encourages rapid development
|
||||
and clean, pragmatic design. Thanks for checking it out.
|
||||
|
||||
All documentation is in the "``docs``" directory and online at
|
||||
|
|
|
|||
|
|
@ -471,7 +471,7 @@ SESSION_COOKIE_HTTPONLY = True
|
|||
SESSION_COOKIE_SAMESITE = 'Lax'
|
||||
# Whether to save the session data on every request.
|
||||
SESSION_SAVE_EVERY_REQUEST = False
|
||||
# Whether a user's session cookie expires when the Web browser is closed.
|
||||
# Whether a user's session cookie expires when the web browser is closed.
|
||||
SESSION_EXPIRE_AT_BROWSER_CLOSE = False
|
||||
# The module to store session data
|
||||
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
|
||||
{% block content %}
|
||||
|
||||
<p>{% translate "Thanks for spending some quality time with the Web site today." %}</p>
|
||||
<p>{% translate "Thanks for spending some quality time with the web site today." %}</p>
|
||||
|
||||
<p><a href="{% url 'admin:index' %}">{% translate 'Log in again' %}</a></p>
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ def quote(s):
|
|||
Ensure that primary key values do not confuse the admin URLs by escaping
|
||||
any '/', '_' and ':' and similarly problematic characters.
|
||||
Similar to urllib.parse.quote(), except that the quoting is slightly
|
||||
different so that it doesn't get automatically unquoted by the Web browser.
|
||||
different so that it doesn't get automatically unquoted by the web browser.
|
||||
"""
|
||||
return s.translate(QUOTE_MAP) if isinstance(s, str) else s
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ class AuthenticationMiddleware(MiddlewareMixin):
|
|||
|
||||
class RemoteUserMiddleware(MiddlewareMixin):
|
||||
"""
|
||||
Middleware for utilizing Web-server-provided authentication.
|
||||
Middleware for utilizing web-server-provided authentication.
|
||||
|
||||
If request.user is not authenticated, then this middleware attempts to
|
||||
authenticate the username passed in the ``REMOTE_USER`` request header.
|
||||
|
|
@ -113,7 +113,7 @@ class RemoteUserMiddleware(MiddlewareMixin):
|
|||
|
||||
class PersistentRemoteUserMiddleware(RemoteUserMiddleware):
|
||||
"""
|
||||
Middleware for Web-server provided authentication on logon pages.
|
||||
Middleware for web-server provided authentication on logon pages.
|
||||
|
||||
Like RemoteUserMiddleware but keeps the user authenticated even if
|
||||
the header (``REMOTE_USER``) is not found in the request. Useful
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ class AxisOrder(IntEnum):
|
|||
|
||||
class SpatialReference(GDALBase):
|
||||
"""
|
||||
A wrapper for the OGRSpatialReference object. According to the GDAL Web site,
|
||||
A wrapper for the OGRSpatialReference object. According to the GDAL web site,
|
||||
the SpatialReference object "provide[s] services to represent coordinate
|
||||
systems (projections and datums) and to transform between them."
|
||||
"""
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ from django.utils.regex_helper import _lazy_re_compile
|
|||
|
||||
# Regular expression for recognizing HEXEWKB and WKT. A prophylactic measure
|
||||
# to prevent potentially malicious input from reaching the underlying C
|
||||
# library. Not a substitute for good Web security programming practices.
|
||||
# library. Not a substitute for good web security programming practices.
|
||||
hex_regex = _lazy_re_compile(r'^[0-9A-F]+$', re.I)
|
||||
wkt_regex = _lazy_re_compile(
|
||||
r'^(SRID=(?P<srid>\-?\d+);)?'
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ class Session(AbstractBaseSession):
|
|||
|
||||
For complete documentation on using Sessions in your code, consult
|
||||
the sessions documentation that is shipped with Django (also available
|
||||
on the Django Web site).
|
||||
on the Django web site).
|
||||
"""
|
||||
objects = SessionManager()
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ from django.core.management.commands.runserver import (
|
|||
|
||||
|
||||
class Command(RunserverCommand):
|
||||
help = "Starts a lightweight Web server for development and also serves static files."
|
||||
help = "Starts a lightweight web server for development and also serves static files."
|
||||
|
||||
def add_arguments(self, parser):
|
||||
super().add_arguments(parser)
|
||||
|
|
|
|||
|
|
@ -154,7 +154,7 @@ class Storage:
|
|||
def url(self, name):
|
||||
"""
|
||||
Return an absolute URL where the file's contents can be accessed
|
||||
directly by a Web browser.
|
||||
directly by a web browser.
|
||||
"""
|
||||
raise NotImplementedError('subclasses of Storage must provide a url() method')
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ def get_script_name(environ):
|
|||
|
||||
# If Apache's mod_rewrite had a whack at the URL, Apache set either
|
||||
# SCRIPT_URL or REDIRECT_URL to the full resource URL before applying any
|
||||
# rewrites. Unfortunately not every Web server (lighttpd!) passes this
|
||||
# rewrites. Unfortunately not every web server (lighttpd!) passes this
|
||||
# information through all the time, so FORCE_SCRIPT_NAME, above, is still
|
||||
# needed.
|
||||
script_url = get_bytes_from_wsgi(environ, 'SCRIPT_URL', '') or get_bytes_from_wsgi(environ, 'REDIRECT_URL', '')
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ naiveip_re = _lazy_re_compile(r"""^(?:
|
|||
|
||||
|
||||
class Command(BaseCommand):
|
||||
help = "Starts a lightweight Web server for development."
|
||||
help = "Starts a lightweight web server for development."
|
||||
|
||||
# Validation is called explicitly each time the server is reloaded.
|
||||
requires_system_checks = []
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ def closing_iterator_wrapper(iterable, close):
|
|||
|
||||
def conditional_content_removal(request, response):
|
||||
"""
|
||||
Simulate the behavior of most Web servers by removing the content of
|
||||
Simulate the behavior of most web servers by removing the content of
|
||||
responses for HEAD requests, 1xx, 204, and 304 responses. Ensure
|
||||
compliance with RFC 7230, section 3.3.3.
|
||||
"""
|
||||
|
|
@ -144,7 +144,7 @@ class ClientHandler(BaseHandler):
|
|||
# Request goes through middleware.
|
||||
response = self.get_response(request)
|
||||
|
||||
# Simulate behaviors of most Web servers.
|
||||
# Simulate behaviors of most web servers.
|
||||
conditional_content_removal(request, response)
|
||||
|
||||
# Attach the originating request to the response so that it could be
|
||||
|
|
@ -190,7 +190,7 @@ class AsyncClientHandler(BaseHandler):
|
|||
request._dont_enforce_csrf_checks = not self.enforce_csrf_checks
|
||||
# Request goes through middleware.
|
||||
response = await self.get_response_async(request)
|
||||
# Simulate behaviors of most Web servers.
|
||||
# Simulate behaviors of most web servers.
|
||||
conditional_content_removal(request, response)
|
||||
# Attach the originating ASGI request to the response so that it could
|
||||
# be later retrieved.
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ class MultiValueDict(dict):
|
|||
>>> d.setlist('lastname', ['Holovaty', 'Willison'])
|
||||
|
||||
This class exists to solve the irritating problem raised by cgi.parse_qs,
|
||||
which returns a list for every key, even though most Web forms submit
|
||||
which returns a list for every key, even though most web forms submit
|
||||
single name-value pairs.
|
||||
"""
|
||||
def __init__(self, key_to_list_mapping=()):
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Sample usage:
|
|||
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||
... title="Poynter E-Media Tidbits",
|
||||
... link="http://www.poynter.org/column.asp?id=31",
|
||||
... description="A group Weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... description="A group blog by the sharpest minds in online media/journalism/publishing.",
|
||||
... language="en",
|
||||
... )
|
||||
>>> feed.add_item(
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ def csrf_failure(request, reason="", template_name=CSRF_FAILURE_TEMPLATE_NAME):
|
|||
'no_referer': reason == REASON_NO_REFERER,
|
||||
'no_referer1': _(
|
||||
'You are seeing this message because this HTTPS site requires a '
|
||||
'“Referer header” to be sent by your Web browser, but none was '
|
||||
'“Referer header” to be sent by your web browser, but none was '
|
||||
'sent. This header is required for security reasons, to ensure '
|
||||
'that your browser is not being hijacked by third parties.'),
|
||||
'no_referer2': _(
|
||||
|
|
|
|||
|
|
@ -317,7 +317,7 @@ latex_documents = [
|
|||
man_pages = [(
|
||||
'ref/django-admin',
|
||||
'django-admin',
|
||||
'Utility script for the Django Web framework',
|
||||
'Utility script for the Django web framework',
|
||||
['Django Software Foundation'],
|
||||
1
|
||||
)]
|
||||
|
|
|
|||
|
|
@ -5,18 +5,18 @@ FAQ: General
|
|||
Why does this project exist?
|
||||
============================
|
||||
|
||||
Django grew from a very practical need: World Online, a newspaper Web
|
||||
operation, is responsible for building intensive Web applications on journalism
|
||||
Django grew from a very practical need: World Online, a newspaper web
|
||||
operation, is responsible for building intensive web applications on journalism
|
||||
deadlines. In the fast-paced newsroom, World Online often has only a matter of
|
||||
hours to take a complicated Web application from concept to public launch.
|
||||
hours to take a complicated web application from concept to public launch.
|
||||
|
||||
At the same time, the World Online Web developers have consistently been
|
||||
perfectionists when it comes to following best practices of Web development.
|
||||
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 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
|
||||
a generic web development framework that let them build web applications more
|
||||
and more quickly. They tweaked this framework constantly, adding improvements
|
||||
over two years.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Yes. Compared to development time, hardware is cheap, and so Django is
|
|||
designed to take advantage of as much hardware as you can throw at it.
|
||||
|
||||
Django uses a "shared-nothing" architecture, which means you can add hardware
|
||||
at any level -- database servers, caching servers or Web/application servers.
|
||||
at any level -- database servers, caching servers or web/application servers.
|
||||
|
||||
The framework cleanly separates components such as its database layer and
|
||||
application layer. And it ships with a simple-yet-powerful
|
||||
|
|
@ -67,7 +67,7 @@ application layer. And it ships with a simple-yet-powerful
|
|||
Who's behind this?
|
||||
==================
|
||||
|
||||
Django was originally developed at World Online, the Web department of a
|
||||
Django was originally developed at World Online, the web department of a
|
||||
newspaper in Lawrence, Kansas, USA. Django's now run by an international
|
||||
`team of volunteers <https://www.djangoproject.com/foundation/teams/>`_.
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ us.
|
|||
<Framework X> does <feature Y> -- why doesn't Django?
|
||||
=====================================================
|
||||
|
||||
We're well aware that there are other awesome Web frameworks out there, and
|
||||
We're well aware that there are other awesome web frameworks out there, and
|
||||
we're not averse to borrowing ideas where appropriate. However, Django was
|
||||
developed precisely because we were unhappy with the status quo, so please be
|
||||
aware that "because <Framework X> does it" is not going to be sufficient reason
|
||||
|
|
@ -137,7 +137,7 @@ Why did you write all of Django from scratch, instead of using other Python libr
|
|||
======================================================================================
|
||||
|
||||
When Django was originally written, Adrian and Simon spent quite a bit of time
|
||||
exploring the various Python Web frameworks available.
|
||||
exploring the various Python web frameworks available.
|
||||
|
||||
In our opinion, none of them were completely up to snuff.
|
||||
|
||||
|
|
@ -162,7 +162,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 websites.
|
||||
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.
|
||||
|
|
@ -179,7 +179,7 @@ How can I download the Django documentation to read it offline?
|
|||
|
||||
The Django docs are available in the ``docs`` directory of each Django tarball
|
||||
release. These docs are in reST (reStructuredText) format, and each text file
|
||||
corresponds to a Web page on the official Django site.
|
||||
corresponds to a web page on the official Django site.
|
||||
|
||||
Because the documentation is :source:`stored in revision control <docs>`, you
|
||||
can browse documentation changes just like you can browse code changes.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ required for some use cases, but you'll receive an error about them as they're
|
|||
needed.
|
||||
|
||||
For a development environment -- if you just want to experiment with Django --
|
||||
you don't need to have a separate Web server installed or database server.
|
||||
you don't need to have a separate web server installed or database server.
|
||||
|
||||
Django comes with its own :djadmin:`lightweight development server<runserver>`.
|
||||
For a production environment, Django follows the WSGI spec, :pep:`3333`, which
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Using a :class:`~django.db.models.FileField` or an
|
|||
the full path to a directory where you'd like Django to store uploaded
|
||||
files. (For performance, these files are not stored in the database.)
|
||||
Define :setting:`MEDIA_URL` as the base public URL of that directory.
|
||||
Make sure that this directory is writable by the Web server's user
|
||||
Make sure that this directory is writable by the web server's user
|
||||
account.
|
||||
|
||||
#. Add the :class:`~django.db.models.FileField` or
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ How to authenticate using ``REMOTE_USER``
|
|||
=========================================
|
||||
|
||||
This document describes how to make use of external authentication sources
|
||||
(where the Web server sets the ``REMOTE_USER`` environment variable) in your
|
||||
(where the web server sets the ``REMOTE_USER`` environment variable) in your
|
||||
Django applications. This type of authentication solution is typically seen on
|
||||
intranet sites, with single sign-on solutions such as IIS and Integrated
|
||||
Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `Cosign`_,
|
||||
|
|
@ -15,7 +15,7 @@ Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `Cosign`_,
|
|||
.. _WebAuth: https://uit.stanford.edu/service/authentication
|
||||
.. _mod_auth_sspi: https://sourceforge.net/projects/mod-auth-sspi
|
||||
|
||||
When the Web server takes care of authentication it typically sets the
|
||||
When the web server takes care of authentication it typically sets the
|
||||
``REMOTE_USER`` environment variable for use in the underlying application. In
|
||||
Django, ``REMOTE_USER`` is made available in the :attr:`request.META
|
||||
<django.http.HttpRequest.META>` attribute. Django can be configured to make
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ you use a wildcard, you must perform your own validation of the ``Host`` HTTP
|
|||
header, or otherwise ensure that you aren't vulnerable to this category of
|
||||
attacks.
|
||||
|
||||
You should also configure the Web server that sits in front of Django to
|
||||
You should also configure the web server that sits in front of Django to
|
||||
validate the host. It should respond with a static error page or ignore
|
||||
requests for incorrect hosts instead of forwarding the request to Django. This
|
||||
way you'll avoid spurious errors in your Django logs (or emails if you have
|
||||
|
|
@ -249,5 +249,5 @@ Django includes default views and templates for several HTTP error codes. You
|
|||
may want to override the default templates by creating the following templates
|
||||
in your root template directory: ``404.html``, ``500.html``, ``403.html``, and
|
||||
``400.html``. The :ref:`default error views <error-views>` that use these
|
||||
templates should suffice for 99% of Web applications, but you can
|
||||
templates should suffice for 99% of web applications, but you can
|
||||
:ref:`customize them <customizing-error-views>` as well.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Deploying Django
|
||||
================
|
||||
|
||||
Django is full of shortcuts to make Web developers' lives easier, but all
|
||||
Django is full of shortcuts to make web developers' lives easier, but all
|
||||
those tools are of no use if you can't easily deploy your sites. Since Django's
|
||||
inception, ease of deployment has been a major goal.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ make that communication happen.
|
|||
|
||||
Django currently supports two interfaces: WSGI and ASGI.
|
||||
|
||||
* `WSGI`_ is the main Python standard for communicating between Web servers and
|
||||
* `WSGI`_ is the main Python standard for communicating between web servers and
|
||||
applications, but it only supports synchronous code.
|
||||
|
||||
* `ASGI`_ is the new, asynchronous-friendly standard that will allow your
|
||||
|
|
|
|||
|
|
@ -131,10 +131,10 @@ mode`_.
|
|||
Serving files
|
||||
=============
|
||||
|
||||
Django doesn't serve files itself; it leaves that job to whichever Web
|
||||
Django doesn't serve files itself; it leaves that job to whichever web
|
||||
server you choose.
|
||||
|
||||
We recommend using a separate Web server -- i.e., one that's not also running
|
||||
We recommend using a separate web server -- i.e., one that's not also running
|
||||
Django -- for serving media. Here are some good choices:
|
||||
|
||||
* Nginx_
|
||||
|
|
@ -189,15 +189,15 @@ When :mod:`django.contrib.staticfiles` is in :setting:`INSTALLED_APPS`, the
|
|||
Django development server automatically serves the static files of the
|
||||
admin app (and any other installed apps). This is however not the case when you
|
||||
use any other server arrangement. You're responsible for setting up Apache, or
|
||||
whichever Web server you're using, to serve the admin files.
|
||||
whichever web server you're using, to serve the admin files.
|
||||
|
||||
The admin files live in (:file:`django/contrib/admin/static/admin`) of the
|
||||
Django distribution.
|
||||
|
||||
We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
|
||||
admin files (along with a Web server as outlined in the previous section; this
|
||||
admin files (along with a web server as outlined in the previous section; this
|
||||
means using the :djadmin:`collectstatic` management command to collect the
|
||||
static files in :setting:`STATIC_ROOT`, and then configuring your Web server to
|
||||
static files in :setting:`STATIC_ROOT`, and then configuring your web server to
|
||||
serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but here are three
|
||||
other approaches:
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ command. For example:
|
|||
uWSGI model
|
||||
-----------
|
||||
|
||||
uWSGI operates on a client-server model. Your Web server (e.g., nginx, Apache)
|
||||
uWSGI operates on a client-server model. Your web server (e.g., nginx, Apache)
|
||||
communicates with a ``django-uwsgi`` "worker" process to serve dynamic content.
|
||||
|
||||
Configuring and starting the uWSGI server for Django
|
||||
|
|
|
|||
|
|
@ -64,9 +64,9 @@ not found" errors). Django sends emails about 404 errors when:
|
|||
If those conditions are met, Django will email the users listed in the
|
||||
:setting:`MANAGERS` setting whenever your code raises a 404 and the request has
|
||||
a referer. It doesn't bother to email for 404s that don't have a referer --
|
||||
those are usually people typing in broken URLs or broken Web bots. It also
|
||||
those are usually people typing in broken URLs or broken web bots. It also
|
||||
ignores 404s when the referer is equal to the requested URL, since this
|
||||
behavior is from broken Web bots too.
|
||||
behavior is from broken web bots too.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ mention:
|
|||
:mimetype:`application/octet-stream` binary content.
|
||||
|
||||
* When ``as_attachment=True`` is passed to ``FileResponse``, it sets the
|
||||
appropriate ``Content-Disposition`` header and that tells Web browsers to
|
||||
appropriate ``Content-Disposition`` header and that tells web browsers to
|
||||
pop-up a dialog box prompting/confirming how to handle the document even if a
|
||||
default is set on the machine. If the ``as_attachment`` parameter is omitted,
|
||||
browsers will handle the PDF using whatever program/plugin they've been
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ multiple web servers.
|
|||
Serving static files from a dedicated server
|
||||
--------------------------------------------
|
||||
|
||||
Most larger Django sites use a separate Web server -- i.e., one that's not also
|
||||
Most larger Django sites use a separate web server -- i.e., one that's not also
|
||||
running Django -- for serving static files. This server often runs a different
|
||||
type of web server -- faster but less full-featured. Some common choices are:
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Serving static files from a cloud service or CDN
|
|||
Another common tactic is to serve static files from a cloud storage provider
|
||||
like Amazon's S3 and/or a CDN (content delivery network). This lets you
|
||||
ignore the problems of serving static files and can often make for
|
||||
faster-loading Web pages (especially when using a CDN).
|
||||
faster-loading web pages (especially when using a CDN).
|
||||
|
||||
When using these services, the basic workflow would look a bit like the above,
|
||||
except that instead of using ``rsync`` to transfer your static files to the
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Django has a lot of documentation. A high-level overview of how it's organized
|
|||
will help you know where to look for certain things:
|
||||
|
||||
* :doc:`Tutorials </intro/index>` take you by the hand through a series of
|
||||
steps to create a Web application. Start here if you're new to Django or Web
|
||||
steps to create a web application. Start here if you're new to Django or web
|
||||
application development. Also look at the ":ref:`index-first-steps`".
|
||||
|
||||
* :doc:`Topic guides </topics/index>` discuss key topics and concepts at a
|
||||
|
|
@ -70,7 +70,7 @@ The model layer
|
|||
===============
|
||||
|
||||
Django provides an abstraction layer (the "models") for structuring and
|
||||
manipulating the data of your Web application. Learn more about it below:
|
||||
manipulating the data of your web application. Learn more about it below:
|
||||
|
||||
* **Models:**
|
||||
:doc:`Introduction to models <topics/db/models>` |
|
||||
|
|
@ -241,7 +241,7 @@ most popular features:
|
|||
Security
|
||||
========
|
||||
|
||||
Security is a topic of paramount importance in the development of Web
|
||||
Security is a topic of paramount importance in the development of web
|
||||
applications and Django provides multiple protection tools and mechanisms:
|
||||
|
||||
* :doc:`Security overview <topics/security>`
|
||||
|
|
@ -261,7 +261,7 @@ regions:
|
|||
* :doc:`Overview <topics/i18n/index>` |
|
||||
:doc:`Internationalization <topics/i18n/translation>` |
|
||||
:ref:`Localization <how-to-create-language-files>` |
|
||||
:doc:`Localized Web UI formatting and form input <topics/i18n/formatting>`
|
||||
:doc:`Localized web UI formatting and form input <topics/i18n/formatting>`
|
||||
* :doc:`Time zones </topics/i18n/timezones>`
|
||||
|
||||
Performance and optimization
|
||||
|
|
@ -276,13 +276,13 @@ Geographic framework
|
|||
====================
|
||||
|
||||
:doc:`GeoDjango <ref/contrib/gis/index>` intends to be a world-class geographic
|
||||
Web framework. Its goal is to make it as easy as possible to build GIS Web
|
||||
web framework. Its goal is to make it as easy as possible to build GIS web
|
||||
applications and harness the power of spatially enabled data.
|
||||
|
||||
Common Web application tools
|
||||
Common web application tools
|
||||
============================
|
||||
|
||||
Django offers multiple tools commonly needed in the development of Web
|
||||
Django offers multiple tools commonly needed in the development of web
|
||||
applications:
|
||||
|
||||
* **Authentication:**
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ If you think working *with* Django is fun, wait until you start working *on*
|
|||
it. Really, **ANYONE** can do something to help make Django better and greater!
|
||||
|
||||
This contributing guide contains everything you need to know to help build the
|
||||
Django Web framework. Browse the following sections to find out how:
|
||||
Django web framework. Browse the following sections to find out how:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Next, clone your fork, install some requirements, and run the tests:
|
|||
|
||||
Installing the requirements will likely require some operating system packages
|
||||
that your computer doesn't have installed. You can usually figure out which
|
||||
package to install by doing a Web search for the last line or so of the error
|
||||
package to install by doing a web search for the last line or so of the error
|
||||
message. Try adding your operating system to the search query if needed.
|
||||
|
||||
If you have trouble installing the requirements, you can skip that step. See
|
||||
|
|
@ -246,7 +246,7 @@ labels.
|
|||
Running the Selenium tests
|
||||
--------------------------
|
||||
|
||||
Some tests require Selenium and a Web browser. To run these tests, you must
|
||||
Some tests require Selenium and a web browser. To run these tests, you must
|
||||
install the selenium_ package and run the tests with the
|
||||
``--selenium=<BROWSERS>`` option. For example, if you have Firefox and Google
|
||||
Chrome installed:
|
||||
|
|
@ -302,7 +302,7 @@ like so:
|
|||
|
||||
If you encounter an error during the installation, your system might be missing
|
||||
a dependency for one or more of the Python packages. Consult the failing
|
||||
package's documentation or search the Web with the error message that you
|
||||
package's documentation or search the web with the error message that you
|
||||
encounter.
|
||||
|
||||
You can also install the database adapter(s) of your choice using
|
||||
|
|
|
|||
|
|
@ -160,8 +160,7 @@ documentation:
|
|||
* **subclass** -- it's a single word without a hyphen, both as a verb
|
||||
("subclass that model") and as a noun ("create a subclass").
|
||||
|
||||
* **Web**, **World Wide Web**, **the Web** -- note Web is always
|
||||
capitalized when referring to the World Wide Web.
|
||||
* **the web**, **web framework** -- it's not capitalized.
|
||||
|
||||
* **website** -- use one word, without capitalization.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Principles
|
|||
|
||||
The Django Project is managed by a team of volunteers pursuing three goals:
|
||||
|
||||
- Driving the development of the Django Web Framework,
|
||||
- Driving the development of the Django web framework,
|
||||
- Fostering the ecosystem of Django-related software,
|
||||
- Leading the Django community in accordance with the values described in the
|
||||
`Django Code of Conduct`_.
|
||||
|
|
@ -132,7 +132,7 @@ Role
|
|||
|
||||
The technical board is a group of experienced and active committers who steer
|
||||
technical choices. Their main concern is to maintain the quality and stability
|
||||
of the Django Web Framework.
|
||||
of the Django web framework.
|
||||
|
||||
Prerogatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -208,7 +208,7 @@ Django ``tests/`` directory and then running:
|
|||
|
||||
If you encounter an error during the installation, your system might be missing
|
||||
a dependency for one or more of the Python packages. Consult the failing
|
||||
package's documentation or search the Web with the error message that you
|
||||
package's documentation or search the web with the error message that you
|
||||
encounter.
|
||||
|
||||
Now we are ready to run the test suite. If you're using GNU/Linux, macOS, or
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Getting started
|
||||
===============
|
||||
|
||||
New to Django? Or to Web development in general? Well, you came to the right
|
||||
New to Django? Or to web development in general? Well, you came to the right
|
||||
place: read this material to quickly get up and running.
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ while you walk through the introduction.
|
|||
Install Python
|
||||
==============
|
||||
|
||||
Being a Python Web framework, Django requires Python. See
|
||||
Being a Python web framework, Django requires Python. See
|
||||
:ref:`faq-python-version-support` for details. Python includes a lightweight
|
||||
database called SQLite_ so you won't need to set up a database just yet.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ Django at a glance
|
|||
==================
|
||||
|
||||
Because Django was developed in a fast-paced newsroom environment, it was
|
||||
designed to make common Web-development tasks fast and easy. Here's an informal
|
||||
overview of how to write a database-driven Web app with Django.
|
||||
designed to make common web development tasks fast and easy. Here's an informal
|
||||
overview of how to write a database-driven web app with Django.
|
||||
|
||||
The goal of this document is to give you enough technical specifics to
|
||||
understand how Django works, but this isn't intended to be a tutorial or
|
||||
|
|
@ -176,7 +176,7 @@ start populating data. Then, develop the way data is presented to the public.
|
|||
Design your URLs
|
||||
================
|
||||
|
||||
A clean, elegant URL scheme is an important detail in a high-quality Web
|
||||
A clean, elegant URL scheme is an important detail in a high-quality web
|
||||
application. Django encourages beautiful URL design and doesn't put any cruft
|
||||
in URLs, like ``.php`` or ``.asp``.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Advanced tutorial: How to write reusable apps
|
|||
=============================================
|
||||
|
||||
This advanced tutorial begins where :doc:`Tutorial 7 </intro/tutorial07>`
|
||||
left off. We'll be turning our Web-poll into a standalone Python package
|
||||
left off. We'll be turning our web-poll into a standalone Python package
|
||||
you can reuse in new projects and share with other people.
|
||||
|
||||
If you haven't recently completed Tutorials 1–7, we encourage you to review
|
||||
|
|
@ -150,7 +150,7 @@ this. For a small app like polls, this process isn't too difficult.
|
|||
Polls
|
||||
=====
|
||||
|
||||
Polls is a Django app to conduct Web-based polls. For each question,
|
||||
Polls is a Django app to conduct web-based polls. For each question,
|
||||
visitors can choose between a fixed number of answers.
|
||||
|
||||
Detailed documentation is in the "docs" directory.
|
||||
|
|
@ -204,7 +204,7 @@ this. For a small app like polls, this process isn't too difficult.
|
|||
[metadata]
|
||||
name = django-polls
|
||||
version = 0.1
|
||||
description = A Django app to conduct Web-based polls.
|
||||
description = A Django app to conduct web-based polls.
|
||||
long_description = file: README.rst
|
||||
url = https://www.example.com/
|
||||
author = Your Name
|
||||
|
|
|
|||
|
|
@ -67,11 +67,11 @@ work, see :ref:`troubleshooting-django-admin`.
|
|||
.. admonition:: Where should this code live?
|
||||
|
||||
If your background is in plain old PHP (with no use of modern frameworks),
|
||||
you're probably used to putting code under the Web server's document root
|
||||
you're probably used to putting code under the web server's document root
|
||||
(in a place such as ``/var/www``). With Django, you don't do that. It's
|
||||
not a good idea to put any of this Python code within your Web server's
|
||||
not a good idea to put any of this Python code within your web server's
|
||||
document root, because it risks the possibility that people may be able
|
||||
to view your code over the Web. That's not good for security.
|
||||
to view your code over the web. That's not good for security.
|
||||
|
||||
Put your code in some directory **outside** of the document root, such as
|
||||
:file:`/home/mycode`.
|
||||
|
|
@ -148,16 +148,16 @@ You'll see the following output on the command line:
|
|||
Ignore the warning about unapplied database migrations for now; we'll deal
|
||||
with the database shortly.
|
||||
|
||||
You've started the Django development server, a lightweight Web server written
|
||||
You've started the Django development server, a lightweight web server written
|
||||
purely in Python. We've included this with Django so you can develop things
|
||||
rapidly, without having to deal with configuring a production server -- such as
|
||||
Apache -- until you're ready for production.
|
||||
|
||||
Now's a good time to note: **don't** use this server in anything resembling a
|
||||
production environment. It's intended only for use while developing. (We're in
|
||||
the business of making Web frameworks, not Web servers.)
|
||||
the business of making web frameworks, not web servers.)
|
||||
|
||||
Now that the server's running, visit http://127.0.0.1:8000/ with your Web
|
||||
Now that the server's running, visit http://127.0.0.1:8000/ with your web
|
||||
browser. You'll see a "Congratulations!" page, with a rocket taking off.
|
||||
It worked!
|
||||
|
||||
|
|
@ -206,8 +206,8 @@ rather than creating directories.
|
|||
|
||||
.. admonition:: Projects vs. apps
|
||||
|
||||
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
|
||||
What's the difference between a project and an app? An app is a web
|
||||
application that does something -- e.g., a blog system, a database of
|
||||
public records or a small poll app. A project is a collection of
|
||||
configuration and apps for a particular website. A project can contain
|
||||
multiple apps. An app can be in multiple projects.
|
||||
|
|
|
|||
|
|
@ -613,7 +613,7 @@ If the server is not running start it like so:
|
|||
|
||||
$ python manage.py runserver
|
||||
|
||||
Now, open a Web browser and go to "/admin/" on your local domain -- e.g.,
|
||||
Now, open a web browser and go to "/admin/" on your local domain -- e.g.,
|
||||
http://127.0.0.1:8000/admin/. You should see the admin's login screen:
|
||||
|
||||
.. image:: _images/admin01.png
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Writing your first Django app, part 3
|
|||
=====================================
|
||||
|
||||
This tutorial begins where :doc:`Tutorial 2 </intro/tutorial02>` left off. We're
|
||||
continuing the Web-poll application and will focus on creating the public
|
||||
continuing the web-poll application and will focus on creating the public
|
||||
interface -- "views."
|
||||
|
||||
.. admonition:: Where to get help:
|
||||
|
|
@ -14,7 +14,7 @@ interface -- "views."
|
|||
Overview
|
||||
========
|
||||
|
||||
A view is a "type" of Web page in your Django application that generally serves
|
||||
A view is a "type" of web page in your Django application that generally serves
|
||||
a specific function and has a specific template. For example, in a blog
|
||||
application, you might have the following views:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Writing your first Django app, part 4
|
|||
=====================================
|
||||
|
||||
This tutorial begins where :doc:`Tutorial 3 </intro/tutorial03>` left off. We're
|
||||
continuing the Web-poll application and will focus on form processing and
|
||||
continuing the web-poll application and will focus on form processing and
|
||||
cutting down our code.
|
||||
|
||||
.. admonition:: Where to get help:
|
||||
|
|
@ -47,7 +47,7 @@ A quick rundown:
|
|||
``method="get"``) is very important, because the act of submitting this
|
||||
form will alter data server-side. Whenever you create a form that alters
|
||||
data server-side, use ``method="post"``. This tip isn't specific to
|
||||
Django; it's good Web development practice in general.
|
||||
Django; it's good web development practice in general.
|
||||
|
||||
* ``forloop.counter`` indicates how many times the :ttag:`for` tag has gone
|
||||
through its loop
|
||||
|
|
@ -126,7 +126,7 @@ This code includes a few things we haven't covered yet in this tutorial:
|
|||
|
||||
As the Python comment above points out, you should always return an
|
||||
:class:`~django.http.HttpResponseRedirect` after successfully dealing with
|
||||
POST data. This tip isn't specific to Django; it's good Web development
|
||||
POST data. This tip isn't specific to Django; it's good web development
|
||||
practice in general.
|
||||
|
||||
* We are using the :func:`~django.urls.reverse` function in the
|
||||
|
|
@ -204,7 +204,7 @@ The ``detail()`` (from :doc:`Tutorial 3 </intro/tutorial03>`) and ``results()``
|
|||
views are very short -- and, as mentioned above, redundant. The ``index()``
|
||||
view, which displays a list of polls, is similar.
|
||||
|
||||
These views represent a common case of basic Web development: getting data from
|
||||
These views represent a common case of basic web development: getting data from
|
||||
the database according to a parameter passed in the URL, loading a template and
|
||||
returning the rendered template. Because this is so common, Django provides a
|
||||
shortcut, called the "generic views" system.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Writing your first Django app, part 5
|
|||
=====================================
|
||||
|
||||
This tutorial begins where :doc:`Tutorial 4 </intro/tutorial04>` left off.
|
||||
We've built a Web-poll application, and we'll now create some automated tests
|
||||
We've built a web-poll application, and we'll now create some automated tests
|
||||
for it.
|
||||
|
||||
.. admonition:: Where to get help:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Writing your first Django app, part 6
|
|||
=====================================
|
||||
|
||||
This tutorial begins where :doc:`Tutorial 5 </intro/tutorial05>` left off.
|
||||
We've built a tested Web-poll application, and we'll now add a stylesheet and
|
||||
We've built a tested web-poll application, and we'll now add a stylesheet and
|
||||
an image.
|
||||
|
||||
Aside from the HTML generated by the server, web applications generally need
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Writing your first Django app, part 7
|
|||
=====================================
|
||||
|
||||
This tutorial begins where :doc:`Tutorial 6 </intro/tutorial06>` left off. We're
|
||||
continuing the Web-poll application and will focus on customizing Django's
|
||||
continuing the web-poll application and will focus on customizing Django's
|
||||
automatically-generated admin site that we first explored in :doc:`Tutorial 2
|
||||
</intro/tutorial02>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Django's main documentation is broken up into "chunks" designed to fill
|
|||
different needs:
|
||||
|
||||
* The :doc:`introductory material </intro/index>` is designed for people new
|
||||
to Django -- or to Web development in general. It doesn't cover anything
|
||||
to Django -- or to web development in general. It doesn't cover anything
|
||||
in depth, but instead gives a high-level overview of how developing in
|
||||
Django "feels".
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ Where to get it
|
|||
You can read Django documentation in several ways. They are, in order of
|
||||
preference:
|
||||
|
||||
On the Web
|
||||
On the web
|
||||
----------
|
||||
|
||||
The most recent version of the Django documentation lives at
|
||||
|
|
@ -215,8 +215,8 @@ We follow this policy:
|
|||
Django is :ref:`no longer supported<supported-versions-policy>`, that version
|
||||
of the docs won't get any further updates.
|
||||
|
||||
* The `main documentation Web page`_ includes links to documentation for
|
||||
* The `main documentation web page`_ includes links to documentation for
|
||||
previous versions. Be sure you are using the version of the docs
|
||||
corresponding to the version of Django you are using!
|
||||
|
||||
.. _main documentation Web page: https://docs.djangoproject.com/en/dev/
|
||||
.. _main documentation web page: https://docs.djangoproject.com/en/dev/
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ A fundamental goal of Django's stack is `loose coupling and tight cohesion`_.
|
|||
The various layers of the framework shouldn't "know" about each other unless
|
||||
absolutely necessary.
|
||||
|
||||
For example, the template system knows nothing about Web requests, the database
|
||||
For example, the template system knows nothing about web requests, the database
|
||||
layer knows nothing about data display and the view system doesn't care which
|
||||
template system a programmer uses.
|
||||
|
||||
|
|
@ -43,8 +43,8 @@ introspection.
|
|||
Quick development
|
||||
-----------------
|
||||
|
||||
The point of a Web framework in the 21st century is to make the tedious aspects
|
||||
of Web development fast. Django should allow for incredibly quick Web
|
||||
The point of a web framework in the 21st century is to make the tedious aspects
|
||||
of web development fast. Django should allow for incredibly quick web
|
||||
development.
|
||||
|
||||
.. _dry:
|
||||
|
|
@ -173,7 +173,7 @@ Encourage best practices
|
|||
The framework should make it just as easy (or even easier) for a developer to
|
||||
design pretty URLs than ugly ones.
|
||||
|
||||
File extensions in Web-page URLs should be avoided.
|
||||
File extensions in web-page URLs should be avoided.
|
||||
|
||||
Vignette-style commas in URLs deserve severe punishment.
|
||||
|
||||
|
|
@ -185,7 +185,7 @@ Definitive URLs
|
|||
.. index:: urls; definitive
|
||||
|
||||
Technically, ``foo.com/bar`` and ``foo.com/bar/`` are two different URLs, and
|
||||
search-engine robots (and some Web traffic-analyzing tools) would treat them as
|
||||
search-engine robots (and some web traffic-analyzing tools) would treat them as
|
||||
separate pages. Django should make an effort to "normalize" URLs so that
|
||||
search-engine robots don't get confused.
|
||||
|
||||
|
|
|
|||
|
|
@ -334,7 +334,7 @@ Manager methods
|
|||
|
||||
In practice, you probably won't need to use
|
||||
:class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
|
||||
they're used by Web requests, as explained in the next section.
|
||||
they're used by web requests, as explained in the next section.
|
||||
|
||||
``Permission`` model
|
||||
====================
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Finally, there is the :func:`fromfile` factory method which returns a
|
|||
.. admonition:: My logs are filled with GEOS-related errors
|
||||
|
||||
You find many ``TypeError`` or ``AttributeError`` exceptions filling your
|
||||
Web server's log files. This generally means that you are creating GEOS
|
||||
web server's log files. This generally means that you are creating GEOS
|
||||
objects at the top level of some of your Python modules. Then, due to a race
|
||||
condition in the garbage collector, your module is garbage collected before
|
||||
the GEOS object. To prevent this, create :class:`GEOSGeometry` objects
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ GeoDjango
|
|||
.. module:: django.contrib.gis
|
||||
:synopsis: Geographic Information System (GIS) extensions for Django
|
||||
|
||||
GeoDjango intends to be a world-class geographic Web framework. Its goal is to
|
||||
make it as easy as possible to build GIS Web applications and harness the power
|
||||
GeoDjango intends to be a world-class geographic web framework. Its goal is to
|
||||
make it as easy as possible to build GIS web applications and harness the power
|
||||
of spatially enabled data.
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ corresponds to the projection system that will be used to interpret the data
|
|||
in the spatial database. [#fnsrid]_ Projection systems give the context to the
|
||||
coordinates that specify a location. Although the details of `geodesy`__ are
|
||||
beyond the scope of this documentation, the general problem is that the earth
|
||||
is spherical and representations of the earth (e.g., paper maps, Web maps)
|
||||
is spherical and representations of the earth (e.g., paper maps, web maps)
|
||||
are not.
|
||||
|
||||
Most people are familiar with using latitude and longitude to reference a
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@ Introduction
|
|||
============
|
||||
|
||||
GeoDjango is an included contrib module for Django that turns it into a
|
||||
world-class geographic Web framework. GeoDjango strives to make it as simple
|
||||
as possible to create geographic Web applications, like location-based services.
|
||||
world-class geographic web framework. GeoDjango strives to make it as simple
|
||||
as possible to create geographic web applications, like location-based services.
|
||||
Its features include:
|
||||
|
||||
* Django model fields for `OGC`_ geometries and raster data.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ GeoDjango Utilities
|
|||
:synopsis: GeoDjango's collection of utilities.
|
||||
|
||||
The :mod:`django.contrib.gis.utils` module contains various utilities that are
|
||||
useful in creating geospatial Web applications.
|
||||
useful in creating geospatial web applications.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
Django aims to follow Python's :ref:`"batteries included" philosophy
|
||||
<tut-batteries-included>`. It ships with a variety of extra, optional tools
|
||||
that solve common Web-development problems.
|
||||
that solve common web development problems.
|
||||
|
||||
This code lives in ``django/contrib`` in the Django distribution. This document
|
||||
gives a rundown of the packages in ``contrib``, along with any dependencies
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ a :class:`~django.contrib.sitemaps.Sitemap` class (e.g.,
|
|||
A :class:`~django.contrib.sitemaps.Sitemap` class is a Python class that
|
||||
represents a "section" of entries in your sitemap. For example, one
|
||||
:class:`~django.contrib.sitemaps.Sitemap` class could represent all the entries
|
||||
of your Weblog, while another could represent all of the events in your events
|
||||
of your blog, while another could represent all of the events in your events
|
||||
calendar.
|
||||
|
||||
In the simplest case, all these sections get lumped together into one
|
||||
|
|
|
|||
|
|
@ -174,7 +174,7 @@ Getting the current domain for display
|
|||
|
||||
LJWorld.com and Lawrence.com both have email alert functionality, which lets
|
||||
readers sign up to get notifications when news happens. It's pretty basic: A
|
||||
reader signs up on a Web form and immediately gets an email saying,
|
||||
reader signs up on a web form and immediately gets an email saying,
|
||||
"Thanks for your subscription."
|
||||
|
||||
It'd be inefficient and redundant to implement this sign up processing code
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ To create any syndication feed, all you have to do is write a short
|
|||
Python class. You can create as many feeds as you want.
|
||||
|
||||
Django also comes with a lower-level feed-generating API. Use this if
|
||||
you want to generate feeds outside of a Web context, or in some other
|
||||
you want to generate feeds outside of a web context, or in some other
|
||||
lower-level way.
|
||||
|
||||
.. _RSS: https://developer.mozilla.org/en-US/docs/Glossary/RSS
|
||||
|
|
@ -1014,7 +1014,7 @@ For example, to create an Atom 1.0 feed and print it to standard output::
|
|||
>>> from django.utils import feedgenerator
|
||||
>>> from datetime import datetime
|
||||
>>> f = feedgenerator.Atom1Feed(
|
||||
... title="My Weblog",
|
||||
... title="My Blog",
|
||||
... link="https://www.example.com/",
|
||||
... description="In which I write about what I ate today.",
|
||||
... language="en",
|
||||
|
|
|
|||
|
|
@ -918,7 +918,7 @@ detected.
|
|||
|
||||
.. django-admin:: runserver [addrport]
|
||||
|
||||
Starts a lightweight development Web server on the local machine. By default,
|
||||
Starts a lightweight development web server on the local machine. By default,
|
||||
the server runs on port 8000 on the IP address ``127.0.0.1``. You can pass in an
|
||||
IP address and port number explicitly.
|
||||
|
||||
|
|
@ -931,7 +931,7 @@ This server uses the WSGI application object specified by the
|
|||
|
||||
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
||||
security audits or performance tests. (And that's how it's gonna stay. We're in
|
||||
the business of making Web frameworks, not Web servers, so improving this
|
||||
the business of making web frameworks, not web servers, so improving this
|
||||
server to be able to handle a production environment is outside the scope of
|
||||
Django.)
|
||||
|
||||
|
|
@ -1580,12 +1580,12 @@ This is useful in a number of ways:
|
|||
|
||||
* When you're writing :doc:`unit tests </topics/testing/overview>` of how your views
|
||||
act with certain fixture data, you can use ``testserver`` to interact with
|
||||
the views in a Web browser, manually.
|
||||
the views in a web browser, manually.
|
||||
|
||||
* Let's say you're developing your Django application and have a "pristine"
|
||||
copy of a database that you'd like to interact with. You can dump your
|
||||
database to a fixture (using the :djadmin:`dumpdata` command, explained
|
||||
above), then use ``testserver`` to run your Web application with that data.
|
||||
above), then use ``testserver`` to run your web application with that data.
|
||||
With this arrangement, you have the flexibility of messing up your data
|
||||
in any way, knowing that whatever data changes you're making are only
|
||||
being made to a test database.
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Customizing widget instances
|
|||
When Django renders a widget as HTML, it only renders very minimal markup -
|
||||
Django doesn't add class names, or any other widget-specific attributes. This
|
||||
means, for example, that all :class:`TextInput` widgets will appear the same
|
||||
on your Web pages.
|
||||
on your web pages.
|
||||
|
||||
There are two ways to customize widgets: :ref:`per widget instance
|
||||
<styling-widget-instances>` and :ref:`per widget class <styling-widget-classes>`.
|
||||
|
|
@ -145,7 +145,7 @@ provided for each widget will be rendered exactly the same::
|
|||
<tr><th>Url:</th><td><input type="url" name="url" required></td></tr>
|
||||
<tr><th>Comment:</th><td><input type="text" name="comment" required></td></tr>
|
||||
|
||||
On a real Web page, you probably don't want every widget to look the same. You
|
||||
On a real web page, you probably don't want every widget to look the same. You
|
||||
might want a larger input element for the comment, and you might want the
|
||||
'name' widget to have some special CSS class. It is also possible to specify
|
||||
the 'type' attribute to take advantage of the new HTML5 input types. To do
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@ Python logging module <python:logging.handlers>`.
|
|||
|
||||
The ``include_html`` argument of ``AdminEmailHandler`` is used to
|
||||
control whether the traceback email includes an HTML attachment
|
||||
containing the full content of the debug Web page that would have been
|
||||
containing the full content of the debug web page that would have been
|
||||
produced if :setting:`DEBUG` were ``True``. To set this value in your
|
||||
configuration, include it in the handler definition for
|
||||
``django.utils.log.AdminEmailHandler``, like this::
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ Security middleware
|
|||
|
||||
.. warning::
|
||||
If your deployment situation allows, it's usually a good idea to have your
|
||||
front-end Web server perform the functionality provided by the
|
||||
front-end web server perform the functionality provided by the
|
||||
``SecurityMiddleware``. That way, if there are requests that aren't served
|
||||
by Django (such as static media or user-uploaded files), they will have
|
||||
the same protections as requests to your Django application.
|
||||
|
|
@ -222,7 +222,7 @@ you set the :setting:`SECURE_HSTS_SECONDS` setting to a non-zero integer value.
|
|||
|
||||
When enabling HSTS, it's a good idea to first use a small value for testing,
|
||||
for example, :setting:`SECURE_HSTS_SECONDS = 3600<SECURE_HSTS_SECONDS>` for one
|
||||
hour. Each time a Web browser sees the HSTS header from your site, it will
|
||||
hour. Each time a web browser sees the HSTS header from your site, it will
|
||||
refuse to communicate non-securely (using HTTP) with your domain for the given
|
||||
period of time. Once you confirm that all assets are served securely on your
|
||||
site (i.e. HSTS didn't break anything), it's a good idea to increase this value
|
||||
|
|
@ -413,10 +413,10 @@ is ``True``.
|
|||
|
||||
Note that in most deployment situations where Django isn't involved in serving
|
||||
user-uploaded files, this setting won't help you. For example, if your
|
||||
:setting:`MEDIA_URL` is served directly by your front-end Web server (nginx,
|
||||
:setting:`MEDIA_URL` is served directly by your front-end web server (nginx,
|
||||
Apache, etc.) then you'd want to set this header there. On the other hand, if
|
||||
you are using Django to do something like require authorization in order to
|
||||
download files and you cannot set the header using your Web server, this
|
||||
download files and you cannot set the header using your web server, this
|
||||
setting will be useful.
|
||||
|
||||
__ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
|
||||
|
|
@ -486,17 +486,17 @@ Authentication middleware
|
|||
.. class:: AuthenticationMiddleware
|
||||
|
||||
Adds the ``user`` attribute, representing the currently-logged-in user, to
|
||||
every incoming ``HttpRequest`` object. See :ref:`Authentication in Web requests
|
||||
every incoming ``HttpRequest`` object. See :ref:`Authentication in web requests
|
||||
<auth-web-requests>`.
|
||||
|
||||
.. class:: RemoteUserMiddleware
|
||||
|
||||
Middleware for utilizing Web server provided authentication. See
|
||||
Middleware for utilizing web server provided authentication. See
|
||||
:doc:`/howto/auth-remote-user` for usage details.
|
||||
|
||||
.. class:: PersistentRemoteUserMiddleware
|
||||
|
||||
Middleware for utilizing Web server provided authentication when enabled only
|
||||
Middleware for utilizing web server provided authentication when enabled only
|
||||
on the login page. See :ref:`persistent-remote-user-middleware-howto` for usage
|
||||
details.
|
||||
|
||||
|
|
|
|||
|
|
@ -857,7 +857,7 @@ takes a few steps:
|
|||
full path to a directory where you'd like Django to store uploaded files.
|
||||
(For performance, these files are not stored in the database.) Define
|
||||
:setting:`MEDIA_URL` as the base public URL of that directory. Make sure
|
||||
that this directory is writable by the Web server's user account.
|
||||
that this directory is writable by the web server's user account.
|
||||
|
||||
#. Add the :class:`FileField` or :class:`ImageField` to your model, defining
|
||||
the :attr:`~FileField.upload_to` option to specify a subdirectory of
|
||||
|
|
@ -900,7 +900,7 @@ Note that whenever you deal with uploaded files, you should pay close attention
|
|||
to where you're uploading them and what type of files they are, to avoid
|
||||
security holes. *Validate all uploaded files* so that you're sure the files are
|
||||
what you think they are. For example, if you blindly let somebody upload files,
|
||||
without validation, to a directory that's within your Web server's document
|
||||
without validation, to a directory that's within your web server's document
|
||||
root, then somebody could upload a CGI or PHP script and execute that script by
|
||||
visiting its URL on your site. Don't allow that.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
|
|||
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||
understand those documents before reading this one.
|
||||
|
||||
Throughout this reference we'll use the :ref:`example Weblog models
|
||||
Throughout this reference we'll use the :ref:`example blog models
|
||||
<queryset-model-example>` presented in the :doc:`database query guide
|
||||
</topics/db/queries>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
|
|||
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||
understand those documents before reading this one.
|
||||
|
||||
Throughout this reference we'll use the :ref:`example Weblog models
|
||||
Throughout this reference we'll use the :ref:`example blog models
|
||||
<queryset-model-example>` presented in the :doc:`database query guide
|
||||
</topics/db/queries>`.
|
||||
|
||||
|
|
@ -2685,7 +2685,7 @@ For example, to delete all the entries in a particular blog::
|
|||
|
||||
# Delete all the entries belonging to this Blog.
|
||||
>>> Entry.objects.filter(blog=b).delete()
|
||||
(4, {'weblog.Entry': 2, 'weblog.Entry_authors': 2})
|
||||
(4, {'blog.Entry': 2, 'blog.Entry_authors': 2})
|
||||
|
||||
By default, Django's :class:`~django.db.models.ForeignKey` emulates the SQL
|
||||
constraint ``ON DELETE CASCADE`` — in other words, any objects with foreign
|
||||
|
|
@ -2696,7 +2696,7 @@ For example::
|
|||
|
||||
# This will delete all Blogs and all of their Entry objects.
|
||||
>>> blogs.delete()
|
||||
(5, {'weblog.Blog': 1, 'weblog.Entry': 2, 'weblog.Entry_authors': 2})
|
||||
(5, {'blog.Blog': 1, 'blog.Entry': 2, 'blog.Entry_authors': 2})
|
||||
|
||||
This cascade behavior is customizable via the
|
||||
:attr:`~django.db.models.ForeignKey.on_delete` argument to the
|
||||
|
|
|
|||
|
|
@ -57,10 +57,10 @@ All attributes should be considered read-only, unless stated otherwise.
|
|||
|
||||
.. attribute:: HttpRequest.path_info
|
||||
|
||||
Under some Web server configurations, the portion of the URL after the
|
||||
Under some web server configurations, the portion of the URL after the
|
||||
host name is split up into a script prefix portion and a path info
|
||||
portion. The ``path_info`` attribute always contains the path info portion
|
||||
of the path, no matter what Web server is being used. Using this instead
|
||||
of the path, no matter what web server is being used. Using this instead
|
||||
of :attr:`~HttpRequest.path` can make your code easier to move between
|
||||
test and deployment servers.
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ All attributes should be considered read-only, unless stated otherwise.
|
|||
* ``QUERY_STRING`` -- The query string, as a single (unparsed) string.
|
||||
* ``REMOTE_ADDR`` -- The IP address of the client.
|
||||
* ``REMOTE_HOST`` -- The hostname of the client.
|
||||
* ``REMOTE_USER`` -- The user authenticated by the Web server, if any.
|
||||
* ``REMOTE_USER`` -- The user authenticated by the web server, if any.
|
||||
* ``REQUEST_METHOD`` -- A string such as ``"GET"`` or ``"POST"``.
|
||||
* ``SERVER_NAME`` -- The hostname of the server.
|
||||
* ``SERVER_PORT`` -- The port of the server (as a string).
|
||||
|
|
@ -167,7 +167,7 @@ All attributes should be considered read-only, unless stated otherwise.
|
|||
name, so you won't see them in ``META``. This prevents header-spoofing
|
||||
based on ambiguity between underscores and dashes both being normalizing to
|
||||
underscores in WSGI environment variables. It matches the behavior of
|
||||
Web servers like Nginx and Apache 2.4+.
|
||||
web servers like Nginx and Apache 2.4+.
|
||||
|
||||
:attr:`HttpRequest.headers` is a simpler way to access all HTTP-prefixed
|
||||
headers, plus ``CONTENT_LENGTH`` and ``CONTENT_TYPE``.
|
||||
|
|
@ -365,7 +365,7 @@ Methods
|
|||
Mixing HTTP and HTTPS on the same site is discouraged, therefore
|
||||
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
||||
absolute URI with the same scheme the current request has. If you need
|
||||
to redirect users to HTTPS, it's best to let your Web server redirect
|
||||
to redirect users to HTTPS, it's best to let your web server redirect
|
||||
all HTTP traffic to HTTPS.
|
||||
|
||||
.. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
|
||||
|
|
@ -662,7 +662,7 @@ Typical usage is to pass the contents of the page, as a string, bytestring,
|
|||
or :class:`memoryview`, to the :class:`HttpResponse` constructor::
|
||||
|
||||
>>> from django.http import HttpResponse
|
||||
>>> response = HttpResponse("Here's the text of the Web page.")
|
||||
>>> response = HttpResponse("Here's the text of the web page.")
|
||||
>>> response = HttpResponse("Text only, please.", content_type="text/plain")
|
||||
>>> response = HttpResponse(b'Bytestrings are also accepted.')
|
||||
>>> response = HttpResponse(memoryview(b'Memoryview as well.'))
|
||||
|
|
@ -671,7 +671,7 @@ But if you want to add content incrementally, you can use ``response`` as a
|
|||
file-like object::
|
||||
|
||||
>>> response = HttpResponse()
|
||||
>>> response.write("<p>Here's the text of the Web page.</p>")
|
||||
>>> response.write("<p>Here's the text of the web page.</p>")
|
||||
>>> response.write("<p>Here's another paragraph.</p>")
|
||||
|
||||
Passing iterators
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ a model object and return its URL. This is a way of inserting or overriding
|
|||
``get_absolute_url()`` methods on a per-installation basis. Example::
|
||||
|
||||
ABSOLUTE_URL_OVERRIDES = {
|
||||
'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
|
||||
'blogs.blog': lambda o: "/blogs/%s/" % o.slug,
|
||||
'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -805,7 +805,7 @@ directories::
|
|||
]
|
||||
|
||||
Your templates can go anywhere you want, as long as the directories and
|
||||
templates are readable by the Web server. They can have any extension you want,
|
||||
templates are readable by the web server. They can have any extension you want,
|
||||
such as ``.html`` or ``.txt``, or they can have no extension at all.
|
||||
|
||||
Note that these paths should use Unix-style forward slashes, even on Windows.
|
||||
|
|
|
|||
|
|
@ -471,10 +471,10 @@ That would result in a rendered template like this::
|
|||
|
||||
Hello, <b>username
|
||||
|
||||
...which, in turn, would result in the remainder of the Web page being bolded!
|
||||
...which, in turn, would result in the remainder of the web page being bolded!
|
||||
|
||||
Clearly, user-submitted data shouldn't be trusted blindly and inserted directly
|
||||
into your Web pages, because a malicious user could use this kind of hole to
|
||||
into your web pages, because a malicious user could use this kind of hole to
|
||||
do potentially bad things. This type of security exploit is called a
|
||||
`Cross Site Scripting`_ (XSS) attack.
|
||||
|
||||
|
|
|
|||
|
|
@ -216,7 +216,7 @@ Normally, you should always use :func:`~django.urls.reverse` to define URLs
|
|||
within your application. However, if your application constructs part of the
|
||||
URL hierarchy itself, you may occasionally need to generate URLs. In that
|
||||
case, you need to be able to find the base URL of the Django project within
|
||||
its Web server (normally, :func:`~django.urls.reverse` takes care of this for
|
||||
its web server (normally, :func:`~django.urls.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return
|
||||
the script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its web server, this is always ``"/"``.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Returns an element for inclusion in ``urlpatterns``. For example::
|
|||
path('bio/<username>/', views.bio, name='bio'),
|
||||
path('articles/<slug:title>/', views.article, name='article-detail'),
|
||||
path('articles/<slug:title>/<int:section>/', views.section, name='article-section'),
|
||||
path('weblog/', include('blog.urls')),
|
||||
path('blog/', include('blog.urls')),
|
||||
...
|
||||
]
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Returns an element for inclusion in ``urlpatterns``. For example::
|
|||
urlpatterns = [
|
||||
re_path(r'^index/$', views.index, name='index'),
|
||||
re_path(r'^bio/(?P<username>\w+)/$', views.bio, name='bio'),
|
||||
re_path(r'^weblog/', include('blog.urls')),
|
||||
re_path(r'^blog/', include('blog.urls')),
|
||||
...
|
||||
]
|
||||
|
||||
|
|
|
|||
|
|
@ -300,7 +300,7 @@ Sample usage::
|
|||
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||
... title="Poynter E-Media Tidbits",
|
||||
... link="http://www.poynter.org/column.asp?id=31",
|
||||
... description="A group Weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... description="A group blog by the sharpest minds in online media/journalism/publishing.",
|
||||
... language="en",
|
||||
... )
|
||||
>>> feed.add_item(
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Welcome to Django 1.0!
|
|||
|
||||
We've been looking forward to this moment for over three years, and it's finally
|
||||
here. Django 1.0 represents the largest milestone in Django's development to
|
||||
date: a Web framework that a group of perfectionists can truly be proud of.
|
||||
date: a web framework that a group of perfectionists can truly be proud of.
|
||||
|
||||
Django 1.0 represents over three years of community development as an Open
|
||||
Source project. Django's received contributions from hundreds of developers,
|
||||
|
|
|
|||
|
|
@ -422,7 +422,7 @@ Other new features and changes introduced since Django 1.0 include:
|
|||
notably, the memcached backend -- these operations will be atomic, and
|
||||
quite fast.
|
||||
|
||||
* Django now can :doc:`easily delegate authentication to the Web server
|
||||
* Django now can :doc:`easily delegate authentication to the web server
|
||||
</howto/auth-remote-user>` via a new authentication backend that supports
|
||||
the standard ``REMOTE_USER`` environment variable used for this purpose.
|
||||
|
||||
|
|
|
|||
|
|
@ -864,7 +864,7 @@ Miscellaneous
|
|||
|
||||
* The WSGI handler no longer removes content of responses from ``HEAD``
|
||||
requests or responses with a ``status_code`` of 100-199, 204, or 304. Most
|
||||
Web servers already implement this behavior. Responses retrieved using the
|
||||
web servers already implement this behavior. Responses retrieved using the
|
||||
Django test client continue to have these "response fixes" applied.
|
||||
|
||||
* ``Model.__init__()`` now receives ``django.db.models.DEFERRED`` as the value
|
||||
|
|
|
|||
|
|
@ -741,7 +741,7 @@ Miscellaneous
|
|||
to allow including lists inside help text.
|
||||
|
||||
* :class:`~django.middleware.http.ConditionalGetMiddleware` no longer sets the
|
||||
``Date`` header as Web servers set that header. It also no longer sets the
|
||||
``Date`` header as web servers set that header. It also no longer sets the
|
||||
``Content-Length`` header as this is now done by
|
||||
:class:`~django.middleware.common.CommonMiddleware`.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ Host header poisoning
|
|||
Some parts of Django -- independent of end-user-written applications -- make
|
||||
use of full URLs, including domain name, which are generated from the HTTP Host
|
||||
header. Django's documentation has for some time contained notes advising users
|
||||
on how to configure Web servers to ensure that only valid Host headers can reach
|
||||
on how to configure web servers to ensure that only valid Host headers can reach
|
||||
the Django application. However, it has been reported to us that even with the
|
||||
recommended Web server configurations there are still techniques available for
|
||||
tricking many common Web servers into supplying the application with an
|
||||
recommended web server configurations there are still techniques available for
|
||||
tricking many common web servers into supplying the application with an
|
||||
incorrect and possibly malicious Host header.
|
||||
|
||||
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ Host header poisoning
|
|||
Some parts of Django -- independent of end-user-written applications -- make
|
||||
use of full URLs, including domain name, which are generated from the HTTP Host
|
||||
header. Django's documentation has for some time contained notes advising users
|
||||
on how to configure Web servers to ensure that only valid Host headers can reach
|
||||
on how to configure web servers to ensure that only valid Host headers can reach
|
||||
the Django application. However, it has been reported to us that even with the
|
||||
recommended Web server configurations there are still techniques available for
|
||||
tricking many common Web servers into supplying the application with an
|
||||
recommended web server configurations there are still techniques available for
|
||||
tricking many common web servers into supplying the application with an
|
||||
incorrect and possibly malicious Host header.
|
||||
|
||||
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
||||
|
|
|
|||
|
|
@ -331,7 +331,7 @@ Tools for cryptographic signing
|
|||
|
||||
Django 1.4 adds both a low-level API for signing values and a high-level API
|
||||
for setting and reading signed cookies, one of the most common uses of
|
||||
signing in Web applications.
|
||||
signing in web applications.
|
||||
|
||||
See the :doc:`cryptographic signing </topics/signing>` docs for more
|
||||
information.
|
||||
|
|
@ -688,14 +688,14 @@ files included in apps.
|
|||
Starting in Django 1.4, the admin's static files also follow this
|
||||
convention, to make the files easier to deploy. In previous versions of Django,
|
||||
it was also common to define an ``ADMIN_MEDIA_PREFIX`` setting to point to the
|
||||
URL where the admin's static files live on a Web server. This setting has now
|
||||
URL where the admin's static files live on a web server. This setting has now
|
||||
been deprecated and replaced by the more general setting :setting:`STATIC_URL`.
|
||||
Django will now expect to find the admin static files under the URL
|
||||
``<STATIC_URL>/admin/``.
|
||||
|
||||
If you've previously used a URL path for ``ADMIN_MEDIA_PREFIX`` (e.g.
|
||||
``/media/``) simply make sure :setting:`STATIC_URL` and :setting:`STATIC_ROOT`
|
||||
are configured and your Web server serves those files correctly. The
|
||||
are configured and your web server serves those files correctly. The
|
||||
development server continues to serve the admin files just like before. Read
|
||||
the :doc:`static files howto </howto/static-files/index>` for more details.
|
||||
|
||||
|
|
@ -719,7 +719,7 @@ admin app. Our new policy formalizes existing practices: `YUI's A-grade`_
|
|||
browsers should provide a fully-functional admin experience, with the notable
|
||||
exception of Internet Explorer 6, which is no longer supported.
|
||||
|
||||
Released over 10 years ago, IE6 imposes many limitations on modern Web
|
||||
Released over 10 years ago, IE6 imposes many limitations on modern web
|
||||
development. The practical implications of this policy are that contributors
|
||||
are free to improve the admin without consideration for these limitations.
|
||||
|
||||
|
|
|
|||
|
|
@ -591,7 +591,7 @@ Requests and Responses
|
|||
|
||||
* The :class:`~django.middleware.common.BrokenLinkEmailsMiddleware` now
|
||||
ignores 404s when the referer is equal to the requested URL. To circumvent
|
||||
the empty referer check already implemented, some Web bots set the referer to
|
||||
the empty referer check already implemented, some web bots set the referer to
|
||||
the requested URL.
|
||||
|
||||
Templates
|
||||
|
|
|
|||
|
|
@ -306,7 +306,7 @@ Pagination
|
|||
Requests and Responses
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* The :djadmin:`runserver` Web server supports HTTP 1.1.
|
||||
* The :djadmin:`runserver` web server supports HTTP 1.1.
|
||||
|
||||
Templates
|
||||
~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -790,7 +790,6 @@ versioning
|
|||
vertices
|
||||
viewable
|
||||
virtualized
|
||||
Weblog
|
||||
whitespace
|
||||
whitespaces
|
||||
whizbang
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ That's the basic authentication backend that checks the Django users database
|
|||
and queries the built-in permissions. It does not provide protection against
|
||||
brute force attacks via any rate limiting mechanism. You may either implement
|
||||
your own rate limiting mechanism in a custom auth backend, or use the
|
||||
mechanisms provided by most Web servers.
|
||||
mechanisms provided by most web servers.
|
||||
|
||||
The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
|
||||
username and password is valid in multiple backends, Django will stop
|
||||
|
|
|
|||
|
|
@ -347,7 +347,7 @@ inherit the permissions of the concrete model they subclass::
|
|||
|
||||
.. _auth-web-requests:
|
||||
|
||||
Authentication in Web requests
|
||||
Authentication in web requests
|
||||
==============================
|
||||
|
||||
Django uses :doc:`sessions </topics/http/sessions>` and middleware to hook the
|
||||
|
|
@ -451,7 +451,7 @@ How to log a user out
|
|||
|
||||
When you call :func:`~django.contrib.auth.logout()`, the session data for
|
||||
the current request is completely cleaned out. All existing data is
|
||||
removed. This is to prevent another person from using the same Web browser
|
||||
removed. This is to prevent another person from using the same web browser
|
||||
to log in and have access to the previous user's session data. If you want
|
||||
to put anything into the session that will be available to the user
|
||||
immediately after logging out, do that *after* calling
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@ Django's cache framework
|
|||
========================
|
||||
|
||||
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 --
|
||||
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
|
||||
processing-overhead perspective, than your standard
|
||||
read-a-file-off-the-filesystem server arrangement.
|
||||
|
||||
For most Web applications, this overhead isn't a big deal. Most Web
|
||||
For most web applications, this overhead isn't a big deal. Most web
|
||||
applications aren't ``washingtonpost.com`` or ``slashdot.org``; they're small-
|
||||
to medium-sized sites with so-so traffic. But for medium- to high-traffic
|
||||
sites, it's essential to cut as much overhead as possible.
|
||||
|
|
@ -18,7 +18,7 @@ That's where caching comes in.
|
|||
|
||||
To cache something is to save the result of an expensive calculation so that
|
||||
you don't have to perform the calculation next time. Here's some pseudocode
|
||||
explaining how this would work for a dynamically generated Web page::
|
||||
explaining how this would work for a dynamically generated web page::
|
||||
|
||||
given a URL, try finding that page in the cache
|
||||
if the page is in the cache:
|
||||
|
|
@ -297,7 +297,7 @@ setting.
|
|||
|
||||
Make sure the directory pointed-to by this setting either exists and is
|
||||
readable and writable, or that it can be created by the system user under which
|
||||
your Web server runs. Continuing the above example, if your server runs as the
|
||||
your web server runs. Continuing the above example, if your server runs as the
|
||||
user ``apache``, make sure the directory ``/var/tmp/django_cache`` exists and
|
||||
is readable and writable by the user ``apache``, or that it can be created by
|
||||
the user ``apache``.
|
||||
|
|
@ -1129,7 +1129,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
|
||||
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 website.
|
||||
|
||||
|
|
@ -1139,7 +1139,7 @@ Here are a few examples of downstream caches:
|
|||
certain pages, so if you requested a page from ``http://example.com/``, your
|
||||
ISP would send you the page without having to access example.com directly.
|
||||
The maintainers of example.com have no knowledge of this caching; the ISP
|
||||
sits between example.com and your Web browser, handling all of the caching
|
||||
sits between example.com and your web browser, handling all of the caching
|
||||
transparently. Such caching is not possible under HTTPS as it would
|
||||
constitute a man-in-the-middle attack.
|
||||
|
||||
|
|
@ -1148,17 +1148,17 @@ Here are a few examples of downstream caches:
|
|||
performance. In this case, each request first would be handled by the
|
||||
proxy, and it would be passed to your application only if needed.
|
||||
|
||||
* Your Web browser caches pages, too. If a Web page sends out the
|
||||
* Your web browser caches pages, too. If a web page sends out the
|
||||
appropriate headers, your browser will use the local cached copy for
|
||||
subsequent requests to that page, without even contacting the Web page
|
||||
subsequent requests to that page, without even contacting the web page
|
||||
again to see whether it has changed.
|
||||
|
||||
Downstream caching is a nice efficiency boost, but there's a danger to it:
|
||||
Many Web pages' contents differ based on authentication and a host of other
|
||||
Many web pages' contents differ based on authentication and a host of other
|
||||
variables, and cache systems that blindly save pages based purely on URLs could
|
||||
expose incorrect or sensitive data to subsequent visitors to those pages.
|
||||
|
||||
For example, if you operate a Web email system, then the contents of the
|
||||
For example, if you operate a web email system, then the contents of the
|
||||
"inbox" page depend on which user is logged in. If an ISP blindly cached your
|
||||
site, then the first user who logged in through that ISP would have their
|
||||
user-specific inbox page cached for subsequent visitors to the site. That's
|
||||
|
|
@ -1176,7 +1176,7 @@ 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
|
||||
the contents of a Web page depend on a user's language preference, the page is
|
||||
the contents of a web page depend on a user's language preference, the page is
|
||||
said to "vary on language."
|
||||
|
||||
By default, Django's cache system creates its cache keys using the requested
|
||||
|
|
@ -1262,7 +1262,7 @@ A user usually faces two kinds of caches: their own browser cache (a private
|
|||
cache) and their provider's cache (a public cache). A public cache is used by
|
||||
multiple users and controlled by someone else. This poses problems with
|
||||
sensitive data--you don't want, say, your bank account number stored in a
|
||||
public cache. So Web applications need a way to tell caches which data is
|
||||
public cache. So web applications need a way to tell caches which data is
|
||||
private and which is public.
|
||||
|
||||
The solution is to indicate a page's cache should be "private." To do this in
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
Built-in class-based generic views
|
||||
==================================
|
||||
|
||||
Writing Web applications can be monotonous, because we repeat certain patterns
|
||||
Writing web applications can be monotonous, because we repeat certain patterns
|
||||
again and again. Django tries to take away some of that monotony at the model
|
||||
and template layers, but Web developers also experience this boredom at the view
|
||||
and template layers, but web developers also experience this boredom at the view
|
||||
level.
|
||||
|
||||
Django's *generic views* were developed to ease that pain. They take certain
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Conditional View Processing
|
|||
|
||||
HTTP clients can send a number of headers to tell the server about copies of a
|
||||
resource that they have already seen. This is commonly used when retrieving a
|
||||
Web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
something the client has already retrieved. However, the same headers can be
|
||||
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
|
||||
|
||||
|
|
|
|||
|
|
@ -47,14 +47,14 @@ Create a few ``Publications``::
|
|||
|
||||
Create an ``Article``::
|
||||
|
||||
>>> a1 = Article(headline='Django lets you build Web apps easily')
|
||||
>>> a1 = Article(headline='Django lets you build web apps easily')
|
||||
|
||||
You can't associate it with a ``Publication`` until it's been saved::
|
||||
|
||||
>>> a1.publications.add(p1)
|
||||
Traceback (most recent call last):
|
||||
...
|
||||
ValueError: "<Article: Django lets you build Web apps easily>" needs to have a value for field "id" before this many-to-many relationship can be used.
|
||||
ValueError: "<Article: Django lets you build web apps easily>" needs to have a value for field "id" before this many-to-many relationship can be used.
|
||||
|
||||
Save it!
|
||||
::
|
||||
|
|
@ -100,7 +100,7 @@ Create and add a ``Publication`` to an ``Article`` in one step using
|
|||
>>> p2.article_set.all()
|
||||
<QuerySet [<Article: NASA uses Python>]>
|
||||
>>> p1.article_set.all()
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
>>> Publication.objects.get(id=4).article_set.all()
|
||||
<QuerySet [<Article: NASA uses Python>]>
|
||||
|
||||
|
|
@ -108,13 +108,13 @@ Many-to-many relationships can be queried using :ref:`lookups across
|
|||
relationships <lookups-that-span-relationships>`::
|
||||
|
||||
>>> Article.objects.filter(publications__id=1)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
>>> Article.objects.filter(publications__pk=1)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
>>> Article.objects.filter(publications=1)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
>>> Article.objects.filter(publications=p1)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
|
||||
>>> Article.objects.filter(publications__title__startswith="Science")
|
||||
<QuerySet [<Article: NASA uses Python>, <Article: NASA uses Python>]>
|
||||
|
|
@ -132,9 +132,9 @@ The :meth:`~django.db.models.query.QuerySet.count` function respects
|
|||
1
|
||||
|
||||
>>> Article.objects.filter(publications__in=[1,2]).distinct()
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
>>> Article.objects.filter(publications__in=[p1,p2]).distinct()
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
|
||||
|
||||
Reverse m2m queries are supported (i.e., starting at the table that doesn't have
|
||||
a :class:`~django.db.models.ManyToManyField`)::
|
||||
|
|
@ -165,7 +165,7 @@ Excluding a related item works as you would expect, too (although the SQL
|
|||
involved is a little complex)::
|
||||
|
||||
>>> Article.objects.exclude(publications=p2)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>]>
|
||||
|
||||
If we delete a ``Publication``, its ``Articles`` won't be able to access it::
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ If we delete an ``Article``, its ``Publications`` won't be able to access it::
|
|||
|
||||
>>> a2.delete()
|
||||
>>> Article.objects.all()
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>]>
|
||||
>>> p2.article_set.all()
|
||||
<QuerySet []>
|
||||
|
||||
|
|
@ -261,7 +261,7 @@ go::
|
|||
>>> Publication.objects.all()
|
||||
<QuerySet [<Publication: Highlights for Children>, <Publication: The Python Journal>]>
|
||||
>>> Article.objects.all()
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA finds intelligent life on Earth>, <Article: NASA uses Python>, <Article: Oxygen-free diet works wonders>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA finds intelligent life on Earth>, <Article: NASA uses Python>, <Article: Oxygen-free diet works wonders>]>
|
||||
>>> a2.publications.all()
|
||||
<QuerySet [<Publication: The Python Journal>]>
|
||||
|
||||
|
|
@ -269,7 +269,7 @@ Bulk delete some articles - references to deleted objects should go::
|
|||
|
||||
>>> q = Article.objects.filter(headline__startswith='Django')
|
||||
>>> print(q)
|
||||
<QuerySet [<Article: Django lets you build Web apps easily>]>
|
||||
<QuerySet [<Article: Django lets you build web apps easily>]>
|
||||
>>> q.delete()
|
||||
|
||||
After the :meth:`~django.db.models.query.QuerySet.delete`, the
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Understand cached attributes
|
|||
|
||||
As well as caching of the whole ``QuerySet``, there is caching of the result of
|
||||
attributes on ORM objects. In general, attributes that are not callable will be
|
||||
cached. For example, assuming the :ref:`example Weblog models
|
||||
cached. For example, assuming the :ref:`example blog models
|
||||
<queryset-model-example>`::
|
||||
|
||||
>>> entry = Entry.objects.get(id=1)
|
||||
|
|
@ -164,7 +164,7 @@ First, the query will be quicker because of the underlying database index.
|
|||
Also, the query could run much slower if multiple objects match the lookup;
|
||||
having a unique constraint on the column guarantees this will never happen.
|
||||
|
||||
So using the :ref:`example Weblog models <queryset-model-example>`::
|
||||
So using the :ref:`example blog models <queryset-model-example>`::
|
||||
|
||||
>>> entry = Entry.objects.get(id=10)
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ API. Refer to the :doc:`data model reference </ref/models/index>` for full
|
|||
details of all the various model lookup options.
|
||||
|
||||
Throughout this guide (and in the reference), we'll refer to the following
|
||||
models, which comprise a Weblog application:
|
||||
models, which comprise a blog application:
|
||||
|
||||
.. _queryset-model-example:
|
||||
|
||||
|
|
@ -1181,7 +1181,7 @@ object and returns the number of objects deleted and a dictionary with
|
|||
the number of deletions per object type. Example::
|
||||
|
||||
>>> e.delete()
|
||||
(1, {'weblog.Entry': 1})
|
||||
(1, {'blog.Entry': 1})
|
||||
|
||||
You can also delete objects in bulk. Every
|
||||
:class:`~django.db.models.query.QuerySet` has a
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ should be used only for requests that do not affect the state of the system.
|
|||
``GET`` would also be unsuitable for a password form, because the password
|
||||
would appear in the URL, and thus, also in browser history and server logs,
|
||||
all in plain text. Neither would it be suitable for large quantities of data,
|
||||
or for binary data, such as an image. A Web application that uses ``GET``
|
||||
or for binary data, such as an image. A web application that uses ``GET``
|
||||
requests for admin forms is a security risk: it can be easy for an attacker to
|
||||
mimic a form's request to gain access to sensitive parts of the system.
|
||||
``POST``, coupled with other protections like Django's :doc:`CSRF protection
|
||||
|
|
@ -115,7 +115,7 @@ Forms in Django
|
|||
We've described HTML forms briefly, but an HTML ``<form>`` is just one part of
|
||||
the machinery required.
|
||||
|
||||
In the context of a Web application, 'form' might refer to that HTML
|
||||
In the context of a web application, 'form' might refer to that HTML
|
||||
``<form>``, or to the Django :class:`Form` that produces it, or to the
|
||||
structured data returned when it is submitted, or to the end-to-end working
|
||||
collection of these parts.
|
||||
|
|
|
|||
|
|
@ -2,11 +2,11 @@
|
|||
Form Assets (the ``Media`` class)
|
||||
=================================
|
||||
|
||||
Rendering an attractive and easy-to-use Web form requires more than just
|
||||
HTML - it also requires CSS stylesheets, and if you want to use fancy
|
||||
"Web2.0" widgets, you may also need to include some JavaScript on each
|
||||
page. The exact combination of CSS and JavaScript that is required for
|
||||
any given page will depend upon the widgets that are in use on that page.
|
||||
Rendering an attractive and easy-to-use web form requires more than just
|
||||
HTML - it also requires CSS stylesheets, and if you want to use fancy widgets,
|
||||
you may also need to include some JavaScript on each page. The exact
|
||||
combination of CSS and JavaScript that is required for any given page will
|
||||
depend upon the widgets that are in use on that page.
|
||||
|
||||
This is where asset definitions come in. Django allows you to
|
||||
associate different files -- like stylesheets and scripts -- with the
|
||||
|
|
@ -16,7 +16,7 @@ Calendar widget. This widget can then be associated with the CSS and
|
|||
JavaScript that is required to render the calendar. When the Calendar
|
||||
widget is used on a form, Django is able to identify the CSS and
|
||||
JavaScript files that are required, and provide the list of file names
|
||||
in a form suitable for inclusion on your Web page.
|
||||
in a form suitable for inclusion on your web page.
|
||||
|
||||
.. admonition:: Assets and Django Admin
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ caveats:
|
|||
so you can't define ``__init__()`` as requiring any other arguments.
|
||||
|
||||
* Unlike the ``__call__()`` method which is called once per request,
|
||||
``__init__()`` is called only *once*, when the Web server starts.
|
||||
``__init__()`` is called only *once*, when the web server starts.
|
||||
|
||||
Marking middleware as unused
|
||||
----------------------------
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
|
|||
|
||||
You might also want to set the :setting:`SESSION_FILE_PATH` setting (which
|
||||
defaults to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to
|
||||
control where Django stores session files. Be sure to check that your Web
|
||||
control where Django stores session files. Be sure to check that your web
|
||||
server has permissions to read and write to this location.
|
||||
|
||||
.. _cookie-session-backend:
|
||||
|
|
@ -264,7 +264,7 @@ You can edit it multiple times.
|
|||
:class:`~django.contrib.sessions.serializers.PickleSerializer`.
|
||||
|
||||
* If ``value`` is ``0``, the user's session cookie will expire
|
||||
when the user's Web browser is closed.
|
||||
when the user's web browser is closed.
|
||||
|
||||
* If ``value`` is ``None``, the session reverts to using the global
|
||||
session expiry policy.
|
||||
|
|
@ -299,7 +299,7 @@ You can edit it multiple times.
|
|||
.. method:: get_expire_at_browser_close()
|
||||
|
||||
Returns either ``True`` or ``False``, depending on whether the user's
|
||||
session cookie will expire when the user's Web browser is closed.
|
||||
session cookie will expire when the user's web browser is closed.
|
||||
|
||||
.. method:: clear_expired()
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
URL dispatcher
|
||||
==============
|
||||
|
||||
A clean, elegant URL scheme is an important detail in a high-quality Web
|
||||
A clean, elegant URL scheme is an important detail in a high-quality web
|
||||
application. Django lets you design URLs however you want, with no framework
|
||||
limitations.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ Writing views
|
|||
=============
|
||||
|
||||
A view function, or *view* for short, is a Python function that takes a
|
||||
Web request and returns a Web response. This response can be the HTML contents
|
||||
of a Web page, or a redirect, or a 404 error, or an XML document, or an image .
|
||||
web request and returns a web response. This response can be the HTML contents
|
||||
of a web page, or a redirect, or a 404 error, or an XML document, or an image .
|
||||
. . or anything, really. The view itself contains whatever arbitrary logic is
|
||||
necessary to return that response. This code can live anywhere you want, as long
|
||||
as it's on your Python path. There's no other requirement--no "magic," so to
|
||||
|
|
@ -137,7 +137,7 @@ template.
|
|||
Customizing error views
|
||||
=======================
|
||||
|
||||
The default error views in Django should suffice for most Web applications,
|
||||
The default error views in Django should suffice for most web applications,
|
||||
but can easily be overridden if you need any custom behavior. Specify the
|
||||
handlers as seen below in your URLconf (setting them anywhere else will have no
|
||||
effect).
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Internationalization and localization
|
|||
Overview
|
||||
========
|
||||
|
||||
The goal of internationalization and localization is to allow a single Web
|
||||
The goal of internationalization and localization is to allow a single web
|
||||
application to offer its content in languages and formats tailored to the
|
||||
audience.
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ Essentially, Django does two things:
|
|||
|
||||
* It allows developers and template authors to specify which parts of their apps
|
||||
should be translated or formatted for local languages and cultures.
|
||||
* It uses these hooks to localize Web apps for particular users according to
|
||||
* It uses these hooks to localize web apps for particular users according to
|
||||
their preferences.
|
||||
|
||||
Translation depends on the target language, and formatting usually depends on
|
||||
|
|
|
|||
|
|
@ -503,7 +503,7 @@ Setup
|
|||
datetimes, and vice-versa.
|
||||
|
||||
If your application connects to other systems -- for instance, if it queries
|
||||
a Web service -- make sure datetimes are properly specified. To transmit
|
||||
a web service -- make sure datetimes are properly specified. To transmit
|
||||
datetimes safely, their representation should include the UTC offset, or
|
||||
their values should be in UTC (or both!).
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the equivalent of the translation strings in the target language. Once the
|
|||
translators have filled in the message file, it must be compiled. This process
|
||||
relies on the GNU gettext toolset.
|
||||
|
||||
Once this is done, Django takes care of translating Web apps on the fly in each
|
||||
Once this is done, Django takes care of translating web apps on the fly in each
|
||||
available language, according to users' language preferences.
|
||||
|
||||
Django's internationalization hooks are on by default, and that means there's a
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ This document will get you up and running with Django.
|
|||
Install Python
|
||||
==============
|
||||
|
||||
Django is a Python Web framework. See :ref:`faq-python-version-support` for
|
||||
Django is a Python web framework. See :ref:`faq-python-version-support` for
|
||||
details.
|
||||
|
||||
Get the latest version of Python at https://www.python.org/downloads/ or with
|
||||
|
|
@ -34,9 +34,9 @@ memory when the server starts. Code stays in memory throughout the
|
|||
life of an Apache process, which leads to significant performance
|
||||
gains over other server arrangements. In daemon mode, mod_wsgi spawns
|
||||
an independent daemon process that handles requests. The daemon
|
||||
process can run as a different user than the Web server, possibly
|
||||
process can run as a different user than the web server, possibly
|
||||
leading to improved security. The daemon process can be restarted
|
||||
without restarting the entire Apache Web server, possibly making
|
||||
without restarting the entire Apache web server, possibly making
|
||||
refreshing your codebase more seamless. Consult the mod_wsgi
|
||||
documentation to determine which mode is right for your setup. Make
|
||||
sure you have Apache installed with the mod_wsgi module activated.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue