Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate.
This commit is contained in:
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.
|
of the Lawrence Journal-World newspaper in Lawrence, Kansas.
|
||||||
|
|
||||||
Here is an inevitably incomplete list of MUCH-APPRECIATED CONTRIBUTORS --
|
Here is an inevitably incomplete list of MUCH-APPRECIATED CONTRIBUTORS --
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
Django
|
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.
|
and clean, pragmatic design. Thanks for checking it out.
|
||||||
|
|
||||||
All documentation is in the "``docs``" directory and online at
|
All documentation is in the "``docs``" directory and online at
|
||||||
|
|
|
@ -471,7 +471,7 @@ SESSION_COOKIE_HTTPONLY = True
|
||||||
SESSION_COOKIE_SAMESITE = 'Lax'
|
SESSION_COOKIE_SAMESITE = 'Lax'
|
||||||
# Whether to save the session data on every request.
|
# Whether to save the session data on every request.
|
||||||
SESSION_SAVE_EVERY_REQUEST = False
|
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
|
SESSION_EXPIRE_AT_BROWSER_CLOSE = False
|
||||||
# The module to store session data
|
# The module to store session data
|
||||||
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
|
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
|
||||||
|
|
|
@ -7,7 +7,7 @@
|
||||||
|
|
||||||
{% block content %}
|
{% 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>
|
<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
|
Ensure that primary key values do not confuse the admin URLs by escaping
|
||||||
any '/', '_' and ':' and similarly problematic characters.
|
any '/', '_' and ':' and similarly problematic characters.
|
||||||
Similar to urllib.parse.quote(), except that the quoting is slightly
|
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
|
return s.translate(QUOTE_MAP) if isinstance(s, str) else s
|
||||||
|
|
||||||
|
|
|
@ -27,7 +27,7 @@ class AuthenticationMiddleware(MiddlewareMixin):
|
||||||
|
|
||||||
class RemoteUserMiddleware(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
|
If request.user is not authenticated, then this middleware attempts to
|
||||||
authenticate the username passed in the ``REMOTE_USER`` request header.
|
authenticate the username passed in the ``REMOTE_USER`` request header.
|
||||||
|
@ -113,7 +113,7 @@ class RemoteUserMiddleware(MiddlewareMixin):
|
||||||
|
|
||||||
class PersistentRemoteUserMiddleware(RemoteUserMiddleware):
|
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
|
Like RemoteUserMiddleware but keeps the user authenticated even if
|
||||||
the header (``REMOTE_USER``) is not found in the request. Useful
|
the header (``REMOTE_USER``) is not found in the request. Useful
|
||||||
|
|
|
@ -43,7 +43,7 @@ class AxisOrder(IntEnum):
|
||||||
|
|
||||||
class SpatialReference(GDALBase):
|
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
|
the SpatialReference object "provide[s] services to represent coordinate
|
||||||
systems (projections and datums) and to transform between them."
|
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
|
# Regular expression for recognizing HEXEWKB and WKT. A prophylactic measure
|
||||||
# to prevent potentially malicious input from reaching the underlying C
|
# 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)
|
hex_regex = _lazy_re_compile(r'^[0-9A-F]+$', re.I)
|
||||||
wkt_regex = _lazy_re_compile(
|
wkt_regex = _lazy_re_compile(
|
||||||
r'^(SRID=(?P<srid>\-?\d+);)?'
|
r'^(SRID=(?P<srid>\-?\d+);)?'
|
||||||
|
|
|
@ -22,7 +22,7 @@ class Session(AbstractBaseSession):
|
||||||
|
|
||||||
For complete documentation on using Sessions in your code, consult
|
For complete documentation on using Sessions in your code, consult
|
||||||
the sessions documentation that is shipped with Django (also available
|
the sessions documentation that is shipped with Django (also available
|
||||||
on the Django Web site).
|
on the Django web site).
|
||||||
"""
|
"""
|
||||||
objects = SessionManager()
|
objects = SessionManager()
|
||||||
|
|
||||||
|
|
|
@ -6,7 +6,7 @@ from django.core.management.commands.runserver import (
|
||||||
|
|
||||||
|
|
||||||
class Command(RunserverCommand):
|
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):
|
def add_arguments(self, parser):
|
||||||
super().add_arguments(parser)
|
super().add_arguments(parser)
|
||||||
|
|
|
@ -154,7 +154,7 @@ class Storage:
|
||||||
def url(self, name):
|
def url(self, name):
|
||||||
"""
|
"""
|
||||||
Return an absolute URL where the file's contents can be accessed
|
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')
|
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
|
# 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
|
# 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
|
# information through all the time, so FORCE_SCRIPT_NAME, above, is still
|
||||||
# needed.
|
# needed.
|
||||||
script_url = get_bytes_from_wsgi(environ, 'SCRIPT_URL', '') or get_bytes_from_wsgi(environ, 'REDIRECT_URL', '')
|
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):
|
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.
|
# Validation is called explicitly each time the server is reloaded.
|
||||||
requires_system_checks = []
|
requires_system_checks = []
|
||||||
|
|
|
@ -98,7 +98,7 @@ def closing_iterator_wrapper(iterable, close):
|
||||||
|
|
||||||
def conditional_content_removal(request, response):
|
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
|
responses for HEAD requests, 1xx, 204, and 304 responses. Ensure
|
||||||
compliance with RFC 7230, section 3.3.3.
|
compliance with RFC 7230, section 3.3.3.
|
||||||
"""
|
"""
|
||||||
|
@ -144,7 +144,7 @@ class ClientHandler(BaseHandler):
|
||||||
# Request goes through middleware.
|
# Request goes through middleware.
|
||||||
response = self.get_response(request)
|
response = self.get_response(request)
|
||||||
|
|
||||||
# Simulate behaviors of most Web servers.
|
# Simulate behaviors of most web servers.
|
||||||
conditional_content_removal(request, response)
|
conditional_content_removal(request, response)
|
||||||
|
|
||||||
# Attach the originating request to the response so that it could be
|
# 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._dont_enforce_csrf_checks = not self.enforce_csrf_checks
|
||||||
# Request goes through middleware.
|
# Request goes through middleware.
|
||||||
response = await self.get_response_async(request)
|
response = await self.get_response_async(request)
|
||||||
# Simulate behaviors of most Web servers.
|
# Simulate behaviors of most web servers.
|
||||||
conditional_content_removal(request, response)
|
conditional_content_removal(request, response)
|
||||||
# Attach the originating ASGI request to the response so that it could
|
# Attach the originating ASGI request to the response so that it could
|
||||||
# be later retrieved.
|
# be later retrieved.
|
||||||
|
|
|
@ -65,7 +65,7 @@ class MultiValueDict(dict):
|
||||||
>>> d.setlist('lastname', ['Holovaty', 'Willison'])
|
>>> d.setlist('lastname', ['Holovaty', 'Willison'])
|
||||||
|
|
||||||
This class exists to solve the irritating problem raised by cgi.parse_qs,
|
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.
|
single name-value pairs.
|
||||||
"""
|
"""
|
||||||
def __init__(self, key_to_list_mapping=()):
|
def __init__(self, key_to_list_mapping=()):
|
||||||
|
|
|
@ -7,7 +7,7 @@ Sample usage:
|
||||||
>>> feed = feedgenerator.Rss201rev2Feed(
|
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||||
... title="Poynter E-Media Tidbits",
|
... title="Poynter E-Media Tidbits",
|
||||||
... link="http://www.poynter.org/column.asp?id=31",
|
... 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",
|
... language="en",
|
||||||
... )
|
... )
|
||||||
>>> feed.add_item(
|
>>> 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_referer': reason == REASON_NO_REFERER,
|
||||||
'no_referer1': _(
|
'no_referer1': _(
|
||||||
'You are seeing this message because this HTTPS site requires a '
|
'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 '
|
'sent. This header is required for security reasons, to ensure '
|
||||||
'that your browser is not being hijacked by third parties.'),
|
'that your browser is not being hijacked by third parties.'),
|
||||||
'no_referer2': _(
|
'no_referer2': _(
|
||||||
|
|
|
@ -317,7 +317,7 @@ latex_documents = [
|
||||||
man_pages = [(
|
man_pages = [(
|
||||||
'ref/django-admin',
|
'ref/django-admin',
|
||||||
'django-admin',
|
'django-admin',
|
||||||
'Utility script for the Django Web framework',
|
'Utility script for the Django web framework',
|
||||||
['Django Software Foundation'],
|
['Django Software Foundation'],
|
||||||
1
|
1
|
||||||
)]
|
)]
|
||||||
|
|
|
@ -5,18 +5,18 @@ FAQ: General
|
||||||
Why does this project exist?
|
Why does this project exist?
|
||||||
============================
|
============================
|
||||||
|
|
||||||
Django grew from a very practical need: World Online, a newspaper Web
|
Django grew from a very practical need: World Online, a newspaper web
|
||||||
operation, is responsible for building intensive Web applications on journalism
|
operation, is responsible for building intensive web applications on journalism
|
||||||
deadlines. In the fast-paced newsroom, World Online often has only a matter of
|
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
|
At the same time, the World Online web developers have consistently been
|
||||||
perfectionists when it comes to following best practices of Web development.
|
perfectionists when it comes to following best practices of web development.
|
||||||
|
|
||||||
In fall 2003, the World Online developers (Adrian Holovaty and Simon Willison)
|
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
|
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
|
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
|
and more quickly. They tweaked this framework constantly, adding improvements
|
||||||
over two years.
|
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.
|
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
|
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
|
The framework cleanly separates components such as its database layer and
|
||||||
application layer. And it ships with a simple-yet-powerful
|
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?
|
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
|
newspaper in Lawrence, Kansas, USA. Django's now run by an international
|
||||||
`team of volunteers <https://www.djangoproject.com/foundation/teams/>`_.
|
`team of volunteers <https://www.djangoproject.com/foundation/teams/>`_.
|
||||||
|
|
||||||
|
@ -127,7 +127,7 @@ us.
|
||||||
<Framework X> does <feature Y> -- why doesn't Django?
|
<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
|
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
|
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
|
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
|
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.
|
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.
|
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
|
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.
|
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
|
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
|
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
|
Because the documentation is :source:`stored in revision control <docs>`, you
|
||||||
can browse documentation changes just like you can browse code changes.
|
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.
|
needed.
|
||||||
|
|
||||||
For a development environment -- if you just want to experiment with Django --
|
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>`.
|
Django comes with its own :djadmin:`lightweight development server<runserver>`.
|
||||||
For a production environment, Django follows the WSGI spec, :pep:`3333`, which
|
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
|
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.)
|
files. (For performance, these files are not stored in the database.)
|
||||||
Define :setting:`MEDIA_URL` as the base public URL of that directory.
|
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.
|
account.
|
||||||
|
|
||||||
#. Add the :class:`~django.db.models.FileField` or
|
#. 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
|
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
|
Django applications. This type of authentication solution is typically seen on
|
||||||
intranet sites, with single sign-on solutions such as IIS and Integrated
|
intranet sites, with single sign-on solutions such as IIS and Integrated
|
||||||
Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `Cosign`_,
|
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
|
.. _WebAuth: https://uit.stanford.edu/service/authentication
|
||||||
.. _mod_auth_sspi: https://sourceforge.net/projects/mod-auth-sspi
|
.. _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
|
``REMOTE_USER`` environment variable for use in the underlying application. In
|
||||||
Django, ``REMOTE_USER`` is made available in the :attr:`request.META
|
Django, ``REMOTE_USER`` is made available in the :attr:`request.META
|
||||||
<django.http.HttpRequest.META>` attribute. Django can be configured to make
|
<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
|
header, or otherwise ensure that you aren't vulnerable to this category of
|
||||||
attacks.
|
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
|
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
|
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
|
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
|
may want to override the default templates by creating the following templates
|
||||||
in your root template directory: ``404.html``, ``500.html``, ``403.html``, and
|
in your root template directory: ``404.html``, ``500.html``, ``403.html``, and
|
||||||
``400.html``. The :ref:`default error views <error-views>` that use these
|
``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.
|
:ref:`customize them <customizing-error-views>` as well.
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
Deploying Django
|
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
|
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.
|
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.
|
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.
|
applications, but it only supports synchronous code.
|
||||||
|
|
||||||
* `ASGI`_ is the new, asynchronous-friendly standard that will allow your
|
* `ASGI`_ is the new, asynchronous-friendly standard that will allow your
|
||||||
|
|
|
@ -131,10 +131,10 @@ mode`_.
|
||||||
Serving files
|
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.
|
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:
|
Django -- for serving media. Here are some good choices:
|
||||||
|
|
||||||
* Nginx_
|
* 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
|
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
|
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
|
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
|
The admin files live in (:file:`django/contrib/admin/static/admin`) of the
|
||||||
Django distribution.
|
Django distribution.
|
||||||
|
|
||||||
We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
|
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
|
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
|
serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but here are three
|
||||||
other approaches:
|
other approaches:
|
||||||
|
|
||||||
|
|
|
@ -37,7 +37,7 @@ command. For example:
|
||||||
uWSGI model
|
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.
|
communicates with a ``django-uwsgi`` "worker" process to serve dynamic content.
|
||||||
|
|
||||||
Configuring and starting the uWSGI server for Django
|
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
|
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
|
: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 --
|
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
|
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::
|
.. note::
|
||||||
|
|
||||||
|
|
|
@ -79,7 +79,7 @@ mention:
|
||||||
:mimetype:`application/octet-stream` binary content.
|
:mimetype:`application/octet-stream` binary content.
|
||||||
|
|
||||||
* When ``as_attachment=True`` is passed to ``FileResponse``, it sets the
|
* 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
|
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,
|
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
|
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
|
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
|
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:
|
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
|
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
|
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
|
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,
|
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
|
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:
|
will help you know where to look for certain things:
|
||||||
|
|
||||||
* :doc:`Tutorials </intro/index>` take you by the hand through a series of
|
* :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`".
|
application development. Also look at the ":ref:`index-first-steps`".
|
||||||
|
|
||||||
* :doc:`Topic guides </topics/index>` discuss key topics and concepts at a
|
* :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
|
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:**
|
* **Models:**
|
||||||
:doc:`Introduction to models <topics/db/models>` |
|
:doc:`Introduction to models <topics/db/models>` |
|
||||||
|
@ -241,7 +241,7 @@ most popular features:
|
||||||
Security
|
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:
|
applications and Django provides multiple protection tools and mechanisms:
|
||||||
|
|
||||||
* :doc:`Security overview <topics/security>`
|
* :doc:`Security overview <topics/security>`
|
||||||
|
@ -261,7 +261,7 @@ regions:
|
||||||
* :doc:`Overview <topics/i18n/index>` |
|
* :doc:`Overview <topics/i18n/index>` |
|
||||||
:doc:`Internationalization <topics/i18n/translation>` |
|
:doc:`Internationalization <topics/i18n/translation>` |
|
||||||
:ref:`Localization <how-to-create-language-files>` |
|
: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>`
|
* :doc:`Time zones </topics/i18n/timezones>`
|
||||||
|
|
||||||
Performance and optimization
|
Performance and optimization
|
||||||
|
@ -276,13 +276,13 @@ Geographic framework
|
||||||
====================
|
====================
|
||||||
|
|
||||||
:doc:`GeoDjango <ref/contrib/gis/index>` intends to be a world-class geographic
|
: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.
|
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:
|
applications:
|
||||||
|
|
||||||
* **Authentication:**
|
* **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!
|
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
|
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::
|
.. toctree::
|
||||||
:maxdepth: 2
|
: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
|
Installing the requirements will likely require some operating system packages
|
||||||
that your computer doesn't have installed. You can usually figure out which
|
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.
|
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
|
If you have trouble installing the requirements, you can skip that step. See
|
||||||
|
@ -246,7 +246,7 @@ labels.
|
||||||
Running the Selenium tests
|
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
|
install the selenium_ package and run the tests with the
|
||||||
``--selenium=<BROWSERS>`` option. For example, if you have Firefox and Google
|
``--selenium=<BROWSERS>`` option. For example, if you have Firefox and Google
|
||||||
Chrome installed:
|
Chrome installed:
|
||||||
|
@ -302,7 +302,7 @@ like so:
|
||||||
|
|
||||||
If you encounter an error during the installation, your system might be missing
|
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
|
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.
|
encounter.
|
||||||
|
|
||||||
You can also install the database adapter(s) of your choice using
|
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** -- it's a single word without a hyphen, both as a verb
|
||||||
("subclass that model") and as a noun ("create a subclass").
|
("subclass that model") and as a noun ("create a subclass").
|
||||||
|
|
||||||
* **Web**, **World Wide Web**, **the Web** -- note Web is always
|
* **the web**, **web framework** -- it's not capitalized.
|
||||||
capitalized when referring to the World Wide Web.
|
|
||||||
|
|
||||||
* **website** -- use one word, without capitalization.
|
* **website** -- use one word, without capitalization.
|
||||||
|
|
||||||
|
|
|
@ -7,7 +7,7 @@ Principles
|
||||||
|
|
||||||
The Django Project is managed by a team of volunteers pursuing three goals:
|
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,
|
- Fostering the ecosystem of Django-related software,
|
||||||
- Leading the Django community in accordance with the values described in the
|
- Leading the Django community in accordance with the values described in the
|
||||||
`Django Code of Conduct`_.
|
`Django Code of Conduct`_.
|
||||||
|
@ -132,7 +132,7 @@ Role
|
||||||
|
|
||||||
The technical board is a group of experienced and active committers who steer
|
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
|
technical choices. Their main concern is to maintain the quality and stability
|
||||||
of the Django Web Framework.
|
of the Django web framework.
|
||||||
|
|
||||||
Prerogatives
|
Prerogatives
|
||||||
------------
|
------------
|
||||||
|
|
|
@ -208,7 +208,7 @@ Django ``tests/`` directory and then running:
|
||||||
|
|
||||||
If you encounter an error during the installation, your system might be missing
|
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
|
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.
|
encounter.
|
||||||
|
|
||||||
Now we are ready to run the test suite. If you're using GNU/Linux, macOS, or
|
Now we are ready to run the test suite. If you're using GNU/Linux, macOS, or
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
Getting started
|
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.
|
place: read this material to quickly get up and running.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
|
|
|
@ -10,7 +10,7 @@ while you walk through the introduction.
|
||||||
Install Python
|
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
|
: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.
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
application. Django encourages beautiful URL design and doesn't put any cruft
|
||||||
in URLs, like ``.php`` or ``.asp``.
|
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>`
|
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.
|
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
|
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
|
||||||
=====
|
=====
|
||||||
|
|
||||||
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.
|
visitors can choose between a fixed number of answers.
|
||||||
|
|
||||||
Detailed documentation is in the "docs" directory.
|
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]
|
[metadata]
|
||||||
name = django-polls
|
name = django-polls
|
||||||
version = 0.1
|
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
|
long_description = file: README.rst
|
||||||
url = https://www.example.com/
|
url = https://www.example.com/
|
||||||
author = Your Name
|
author = Your Name
|
||||||
|
|
|
@ -67,11 +67,11 @@ work, see :ref:`troubleshooting-django-admin`.
|
||||||
.. admonition:: Where should this code live?
|
.. admonition:: Where should this code live?
|
||||||
|
|
||||||
If your background is in plain old PHP (with no use of modern frameworks),
|
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
|
(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
|
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
|
Put your code in some directory **outside** of the document root, such as
|
||||||
:file:`/home/mycode`.
|
: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
|
Ignore the warning about unapplied database migrations for now; we'll deal
|
||||||
with the database shortly.
|
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
|
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
|
rapidly, without having to deal with configuring a production server -- such as
|
||||||
Apache -- until you're ready for production.
|
Apache -- until you're ready for production.
|
||||||
|
|
||||||
Now's a good time to note: **don't** use this server in anything resembling a
|
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
|
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.
|
browser. You'll see a "Congratulations!" page, with a rocket taking off.
|
||||||
It worked!
|
It worked!
|
||||||
|
|
||||||
|
@ -206,8 +206,8 @@ rather than creating directories.
|
||||||
|
|
||||||
.. admonition:: Projects vs. apps
|
.. admonition:: Projects vs. apps
|
||||||
|
|
||||||
What's the difference between a project and an app? An app is a Web
|
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
|
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
|
public records or a small poll app. A project is a collection of
|
||||||
configuration and apps for a particular website. A project can contain
|
configuration and apps for a particular website. A project can contain
|
||||||
multiple apps. An app can be in multiple projects.
|
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
|
$ 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:
|
http://127.0.0.1:8000/admin/. You should see the admin's login screen:
|
||||||
|
|
||||||
.. image:: _images/admin01.png
|
.. 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
|
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."
|
interface -- "views."
|
||||||
|
|
||||||
.. admonition:: Where to get help:
|
.. admonition:: Where to get help:
|
||||||
|
@ -14,7 +14,7 @@ interface -- "views."
|
||||||
Overview
|
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
|
a specific function and has a specific template. For example, in a blog
|
||||||
application, you might have the following views:
|
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
|
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.
|
cutting down our code.
|
||||||
|
|
||||||
.. admonition:: Where to get help:
|
.. admonition:: Where to get help:
|
||||||
|
@ -47,7 +47,7 @@ A quick rundown:
|
||||||
``method="get"``) is very important, because the act of submitting this
|
``method="get"``) is very important, because the act of submitting this
|
||||||
form will alter data server-side. Whenever you create a form that alters
|
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
|
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
|
* ``forloop.counter`` indicates how many times the :ttag:`for` tag has gone
|
||||||
through its loop
|
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
|
As the Python comment above points out, you should always return an
|
||||||
:class:`~django.http.HttpResponseRedirect` after successfully dealing with
|
: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.
|
practice in general.
|
||||||
|
|
||||||
* We are using the :func:`~django.urls.reverse` function in the
|
* 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()``
|
views are very short -- and, as mentioned above, redundant. The ``index()``
|
||||||
view, which displays a list of polls, is similar.
|
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
|
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
|
returning the rendered template. Because this is so common, Django provides a
|
||||||
shortcut, called the "generic views" system.
|
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.
|
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.
|
for it.
|
||||||
|
|
||||||
.. admonition:: Where to get help:
|
.. 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.
|
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.
|
an image.
|
||||||
|
|
||||||
Aside from the HTML generated by the server, web applications generally need
|
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
|
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
|
automatically-generated admin site that we first explored in :doc:`Tutorial 2
|
||||||
</intro/tutorial02>`.
|
</intro/tutorial02>`.
|
||||||
|
|
||||||
|
|
|
@ -36,7 +36,7 @@ Django's main documentation is broken up into "chunks" designed to fill
|
||||||
different needs:
|
different needs:
|
||||||
|
|
||||||
* The :doc:`introductory material </intro/index>` is designed for people new
|
* 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
|
in depth, but instead gives a high-level overview of how developing in
|
||||||
Django "feels".
|
Django "feels".
|
||||||
|
|
||||||
|
@ -106,7 +106,7 @@ Where to get it
|
||||||
You can read Django documentation in several ways. They are, in order of
|
You can read Django documentation in several ways. They are, in order of
|
||||||
preference:
|
preference:
|
||||||
|
|
||||||
On the Web
|
On the web
|
||||||
----------
|
----------
|
||||||
|
|
||||||
The most recent version of the Django documentation lives at
|
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
|
Django is :ref:`no longer supported<supported-versions-policy>`, that version
|
||||||
of the docs won't get any further updates.
|
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
|
previous versions. Be sure you are using the version of the docs
|
||||||
corresponding to the version of Django you are using!
|
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
|
The various layers of the framework shouldn't "know" about each other unless
|
||||||
absolutely necessary.
|
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
|
layer knows nothing about data display and the view system doesn't care which
|
||||||
template system a programmer uses.
|
template system a programmer uses.
|
||||||
|
|
||||||
|
@ -43,8 +43,8 @@ introspection.
|
||||||
Quick development
|
Quick development
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
The point of a Web framework in the 21st century is to make the tedious aspects
|
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
|
of web development fast. Django should allow for incredibly quick web
|
||||||
development.
|
development.
|
||||||
|
|
||||||
.. _dry:
|
.. _dry:
|
||||||
|
@ -173,7 +173,7 @@ Encourage best practices
|
||||||
The framework should make it just as easy (or even easier) for a developer to
|
The framework should make it just as easy (or even easier) for a developer to
|
||||||
design pretty URLs than ugly ones.
|
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.
|
Vignette-style commas in URLs deserve severe punishment.
|
||||||
|
|
||||||
|
@ -185,7 +185,7 @@ Definitive URLs
|
||||||
.. index:: urls; definitive
|
.. index:: urls; definitive
|
||||||
|
|
||||||
Technically, ``foo.com/bar`` and ``foo.com/bar/`` are two different URLs, and
|
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
|
separate pages. Django should make an effort to "normalize" URLs so that
|
||||||
search-engine robots don't get confused.
|
search-engine robots don't get confused.
|
||||||
|
|
||||||
|
|
|
@ -334,7 +334,7 @@ Manager methods
|
||||||
|
|
||||||
In practice, you probably won't need to use
|
In practice, you probably won't need to use
|
||||||
:class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
|
: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
|
``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
|
.. admonition:: My logs are filled with GEOS-related errors
|
||||||
|
|
||||||
You find many ``TypeError`` or ``AttributeError`` exceptions filling your
|
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
|
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
|
condition in the garbage collector, your module is garbage collected before
|
||||||
the GEOS object. To prevent this, create :class:`GEOSGeometry` objects
|
the GEOS object. To prevent this, create :class:`GEOSGeometry` objects
|
||||||
|
|
|
@ -5,8 +5,8 @@ GeoDjango
|
||||||
.. module:: django.contrib.gis
|
.. module:: django.contrib.gis
|
||||||
:synopsis: Geographic Information System (GIS) extensions for Django
|
:synopsis: Geographic Information System (GIS) extensions for Django
|
||||||
|
|
||||||
GeoDjango intends to be a world-class geographic Web framework. Its goal is to
|
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
|
make it as easy as possible to build GIS web applications and harness the power
|
||||||
of spatially enabled data.
|
of spatially enabled data.
|
||||||
|
|
||||||
.. toctree::
|
.. 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
|
in the spatial database. [#fnsrid]_ Projection systems give the context to the
|
||||||
coordinates that specify a location. Although the details of `geodesy`__ are
|
coordinates that specify a location. Although the details of `geodesy`__ are
|
||||||
beyond the scope of this documentation, the general problem is that the earth
|
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.
|
are not.
|
||||||
|
|
||||||
Most people are familiar with using latitude and longitude to reference a
|
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
|
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
|
world-class geographic web framework. GeoDjango strives to make it as simple
|
||||||
as possible to create geographic Web applications, like location-based services.
|
as possible to create geographic web applications, like location-based services.
|
||||||
Its features include:
|
Its features include:
|
||||||
|
|
||||||
* Django model fields for `OGC`_ geometries and raster data.
|
* Django model fields for `OGC`_ geometries and raster data.
|
||||||
|
|
|
@ -6,7 +6,7 @@ GeoDjango Utilities
|
||||||
:synopsis: GeoDjango's collection of utilities.
|
:synopsis: GeoDjango's collection of utilities.
|
||||||
|
|
||||||
The :mod:`django.contrib.gis.utils` module contains various utilities that are
|
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::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
|
@ -4,7 +4,7 @@
|
||||||
|
|
||||||
Django aims to follow Python's :ref:`"batteries included" philosophy
|
Django aims to follow Python's :ref:`"batteries included" philosophy
|
||||||
<tut-batteries-included>`. It ships with a variety of extra, optional tools
|
<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
|
This code lives in ``django/contrib`` in the Django distribution. This document
|
||||||
gives a rundown of the packages in ``contrib``, along with any dependencies
|
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
|
A :class:`~django.contrib.sitemaps.Sitemap` class is a Python class that
|
||||||
represents a "section" of entries in your sitemap. For example, one
|
represents a "section" of entries in your sitemap. For example, one
|
||||||
:class:`~django.contrib.sitemaps.Sitemap` class could represent all the entries
|
: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.
|
calendar.
|
||||||
|
|
||||||
In the simplest case, all these sections get lumped together into one
|
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
|
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
|
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."
|
"Thanks for your subscription."
|
||||||
|
|
||||||
It'd be inefficient and redundant to implement this sign up processing code
|
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.
|
Python class. You can create as many feeds as you want.
|
||||||
|
|
||||||
Django also comes with a lower-level feed-generating API. Use this if
|
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.
|
lower-level way.
|
||||||
|
|
||||||
.. _RSS: https://developer.mozilla.org/en-US/docs/Glossary/RSS
|
.. _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 django.utils import feedgenerator
|
||||||
>>> from datetime import datetime
|
>>> from datetime import datetime
|
||||||
>>> f = feedgenerator.Atom1Feed(
|
>>> f = feedgenerator.Atom1Feed(
|
||||||
... title="My Weblog",
|
... title="My Blog",
|
||||||
... link="https://www.example.com/",
|
... link="https://www.example.com/",
|
||||||
... description="In which I write about what I ate today.",
|
... description="In which I write about what I ate today.",
|
||||||
... language="en",
|
... language="en",
|
||||||
|
|
|
@ -918,7 +918,7 @@ detected.
|
||||||
|
|
||||||
.. django-admin:: runserver [addrport]
|
.. 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
|
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.
|
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
|
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
|
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
|
server to be able to handle a production environment is outside the scope of
|
||||||
Django.)
|
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
|
* 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
|
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"
|
* 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
|
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
|
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
|
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
|
in any way, knowing that whatever data changes you're making are only
|
||||||
being made to a test database.
|
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 -
|
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
|
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
|
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
|
There are two ways to customize widgets: :ref:`per widget instance
|
||||||
<styling-widget-instances>` and :ref:`per widget class <styling-widget-classes>`.
|
<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>Url:</th><td><input type="url" name="url" required></td></tr>
|
||||||
<tr><th>Comment:</th><td><input type="text" name="comment" 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
|
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
|
'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
|
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
|
The ``include_html`` argument of ``AdminEmailHandler`` is used to
|
||||||
control whether the traceback email includes an HTML attachment
|
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
|
produced if :setting:`DEBUG` were ``True``. To set this value in your
|
||||||
configuration, include it in the handler definition for
|
configuration, include it in the handler definition for
|
||||||
``django.utils.log.AdminEmailHandler``, like this::
|
``django.utils.log.AdminEmailHandler``, like this::
|
||||||
|
|
|
@ -185,7 +185,7 @@ Security middleware
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
If your deployment situation allows, it's usually a good idea to have your
|
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
|
``SecurityMiddleware``. That way, if there are requests that aren't served
|
||||||
by Django (such as static media or user-uploaded files), they will have
|
by Django (such as static media or user-uploaded files), they will have
|
||||||
the same protections as requests to your Django application.
|
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,
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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.
|
setting will be useful.
|
||||||
|
|
||||||
__ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
|
__ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
|
||||||
|
@ -486,17 +486,17 @@ Authentication middleware
|
||||||
.. class:: AuthenticationMiddleware
|
.. class:: AuthenticationMiddleware
|
||||||
|
|
||||||
Adds the ``user`` attribute, representing the currently-logged-in user, to
|
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>`.
|
<auth-web-requests>`.
|
||||||
|
|
||||||
.. class:: RemoteUserMiddleware
|
.. 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.
|
:doc:`/howto/auth-remote-user` for usage details.
|
||||||
|
|
||||||
.. class:: PersistentRemoteUserMiddleware
|
.. 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
|
on the login page. See :ref:`persistent-remote-user-middleware-howto` for usage
|
||||||
details.
|
details.
|
||||||
|
|
||||||
|
|
|
@ -857,7 +857,7 @@ takes a few steps:
|
||||||
full path to a directory where you'd like Django to store uploaded files.
|
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
|
(For performance, these files are not stored in the database.) Define
|
||||||
:setting:`MEDIA_URL` as the base public URL of that directory. Make sure
|
: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
|
#. Add the :class:`FileField` or :class:`ImageField` to your model, defining
|
||||||
the :attr:`~FileField.upload_to` option to specify a subdirectory of
|
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
|
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
|
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,
|
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
|
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.
|
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
|
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||||
understand those documents before reading this one.
|
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
|
<queryset-model-example>` presented in the :doc:`database query guide
|
||||||
</topics/db/queries>`.
|
</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
|
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||||
understand those documents before reading this one.
|
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
|
<queryset-model-example>` presented in the :doc:`database query guide
|
||||||
</topics/db/queries>`.
|
</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.
|
# Delete all the entries belonging to this Blog.
|
||||||
>>> Entry.objects.filter(blog=b).delete()
|
>>> 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
|
By default, Django's :class:`~django.db.models.ForeignKey` emulates the SQL
|
||||||
constraint ``ON DELETE CASCADE`` — in other words, any objects with foreign
|
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.
|
# This will delete all Blogs and all of their Entry objects.
|
||||||
>>> blogs.delete()
|
>>> 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
|
This cascade behavior is customizable via the
|
||||||
:attr:`~django.db.models.ForeignKey.on_delete` argument to 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
|
.. 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
|
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
|
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
|
of :attr:`~HttpRequest.path` can make your code easier to move between
|
||||||
test and deployment servers.
|
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.
|
* ``QUERY_STRING`` -- The query string, as a single (unparsed) string.
|
||||||
* ``REMOTE_ADDR`` -- The IP address of the client.
|
* ``REMOTE_ADDR`` -- The IP address of the client.
|
||||||
* ``REMOTE_HOST`` -- The hostname 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"``.
|
* ``REQUEST_METHOD`` -- A string such as ``"GET"`` or ``"POST"``.
|
||||||
* ``SERVER_NAME`` -- The hostname of the server.
|
* ``SERVER_NAME`` -- The hostname of the server.
|
||||||
* ``SERVER_PORT`` -- The port of the server (as a string).
|
* ``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
|
name, so you won't see them in ``META``. This prevents header-spoofing
|
||||||
based on ambiguity between underscores and dashes both being normalizing to
|
based on ambiguity between underscores and dashes both being normalizing to
|
||||||
underscores in WSGI environment variables. It matches the behavior of
|
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
|
:attr:`HttpRequest.headers` is a simpler way to access all HTTP-prefixed
|
||||||
headers, plus ``CONTENT_LENGTH`` and ``CONTENT_TYPE``.
|
headers, plus ``CONTENT_LENGTH`` and ``CONTENT_TYPE``.
|
||||||
|
@ -365,7 +365,7 @@ Methods
|
||||||
Mixing HTTP and HTTPS on the same site is discouraged, therefore
|
Mixing HTTP and HTTPS on the same site is discouraged, therefore
|
||||||
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
||||||
absolute URI with the same scheme the current request has. If you need
|
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.
|
all HTTP traffic to HTTPS.
|
||||||
|
|
||||||
.. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
|
.. 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::
|
or :class:`memoryview`, to the :class:`HttpResponse` constructor::
|
||||||
|
|
||||||
>>> from django.http import HttpResponse
|
>>> 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("Text only, please.", content_type="text/plain")
|
||||||
>>> response = HttpResponse(b'Bytestrings are also accepted.')
|
>>> response = HttpResponse(b'Bytestrings are also accepted.')
|
||||||
>>> response = HttpResponse(memoryview(b'Memoryview as well.'))
|
>>> 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::
|
file-like object::
|
||||||
|
|
||||||
>>> response = HttpResponse()
|
>>> 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>")
|
>>> response.write("<p>Here's another paragraph.</p>")
|
||||||
|
|
||||||
Passing iterators
|
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::
|
``get_absolute_url()`` methods on a per-installation basis. Example::
|
||||||
|
|
||||||
ABSOLUTE_URL_OVERRIDES = {
|
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),
|
'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
|
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.
|
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.
|
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
|
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
|
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
|
do potentially bad things. This type of security exploit is called a
|
||||||
`Cross Site Scripting`_ (XSS) attack.
|
`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
|
within your application. However, if your application constructs part of the
|
||||||
URL hierarchy itself, you may occasionally need to generate URLs. In that
|
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
|
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
|
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
|
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 ``"/"``.
|
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('bio/<username>/', views.bio, name='bio'),
|
||||||
path('articles/<slug:title>/', views.article, name='article-detail'),
|
path('articles/<slug:title>/', views.article, name='article-detail'),
|
||||||
path('articles/<slug:title>/<int:section>/', views.section, name='article-section'),
|
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 = [
|
urlpatterns = [
|
||||||
re_path(r'^index/$', views.index, name='index'),
|
re_path(r'^index/$', views.index, name='index'),
|
||||||
re_path(r'^bio/(?P<username>\w+)/$', views.bio, name='bio'),
|
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(
|
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||||
... title="Poynter E-Media Tidbits",
|
... title="Poynter E-Media Tidbits",
|
||||||
... link="http://www.poynter.org/column.asp?id=31",
|
... 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",
|
... language="en",
|
||||||
... )
|
... )
|
||||||
>>> feed.add_item(
|
>>> 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
|
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
|
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
|
Django 1.0 represents over three years of community development as an Open
|
||||||
Source project. Django's received contributions from hundreds of developers,
|
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
|
notably, the memcached backend -- these operations will be atomic, and
|
||||||
quite fast.
|
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
|
</howto/auth-remote-user>` via a new authentication backend that supports
|
||||||
the standard ``REMOTE_USER`` environment variable used for this purpose.
|
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``
|
* 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
|
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.
|
Django test client continue to have these "response fixes" applied.
|
||||||
|
|
||||||
* ``Model.__init__()`` now receives ``django.db.models.DEFERRED`` as the value
|
* ``Model.__init__()`` now receives ``django.db.models.DEFERRED`` as the value
|
||||||
|
|
|
@ -741,7 +741,7 @@ Miscellaneous
|
||||||
to allow including lists inside help text.
|
to allow including lists inside help text.
|
||||||
|
|
||||||
* :class:`~django.middleware.http.ConditionalGetMiddleware` no longer sets the
|
* :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
|
``Content-Length`` header as this is now done by
|
||||||
:class:`~django.middleware.common.CommonMiddleware`.
|
:class:`~django.middleware.common.CommonMiddleware`.
|
||||||
|
|
||||||
|
|
|
@ -16,10 +16,10 @@ Host header poisoning
|
||||||
Some parts of Django -- independent of end-user-written applications -- make
|
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
|
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
|
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
|
the Django application. However, it has been reported to us that even with the
|
||||||
recommended Web server configurations there are still techniques available for
|
recommended web server configurations there are still techniques available for
|
||||||
tricking many common Web servers into supplying the application with an
|
tricking many common web servers into supplying the application with an
|
||||||
incorrect and possibly malicious Host header.
|
incorrect and possibly malicious Host header.
|
||||||
|
|
||||||
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
|
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
|
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
|
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
|
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
|
the Django application. However, it has been reported to us that even with the
|
||||||
recommended Web server configurations there are still techniques available for
|
recommended web server configurations there are still techniques available for
|
||||||
tricking many common Web servers into supplying the application with an
|
tricking many common web servers into supplying the application with an
|
||||||
incorrect and possibly malicious Host header.
|
incorrect and possibly malicious Host header.
|
||||||
|
|
||||||
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
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
|
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
|
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
|
See the :doc:`cryptographic signing </topics/signing>` docs for more
|
||||||
information.
|
information.
|
||||||
|
@ -688,14 +688,14 @@ files included in apps.
|
||||||
Starting in Django 1.4, the admin's static files also follow this
|
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,
|
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
|
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`.
|
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
|
Django will now expect to find the admin static files under the URL
|
||||||
``<STATIC_URL>/admin/``.
|
``<STATIC_URL>/admin/``.
|
||||||
|
|
||||||
If you've previously used a URL path for ``ADMIN_MEDIA_PREFIX`` (e.g.
|
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`
|
``/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
|
development server continues to serve the admin files just like before. Read
|
||||||
the :doc:`static files howto </howto/static-files/index>` for more details.
|
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
|
browsers should provide a fully-functional admin experience, with the notable
|
||||||
exception of Internet Explorer 6, which is no longer supported.
|
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
|
development. The practical implications of this policy are that contributors
|
||||||
are free to improve the admin without consideration for these limitations.
|
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
|
* The :class:`~django.middleware.common.BrokenLinkEmailsMiddleware` now
|
||||||
ignores 404s when the referer is equal to the requested URL. To circumvent
|
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.
|
the requested URL.
|
||||||
|
|
||||||
Templates
|
Templates
|
||||||
|
|
|
@ -306,7 +306,7 @@ Pagination
|
||||||
Requests and Responses
|
Requests and Responses
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
* The :djadmin:`runserver` Web server supports HTTP 1.1.
|
* The :djadmin:`runserver` web server supports HTTP 1.1.
|
||||||
|
|
||||||
Templates
|
Templates
|
||||||
~~~~~~~~~
|
~~~~~~~~~
|
||||||
|
|
|
@ -790,7 +790,6 @@ versioning
|
||||||
vertices
|
vertices
|
||||||
viewable
|
viewable
|
||||||
virtualized
|
virtualized
|
||||||
Weblog
|
|
||||||
whitespace
|
whitespace
|
||||||
whitespaces
|
whitespaces
|
||||||
whizbang
|
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
|
and queries the built-in permissions. It does not provide protection against
|
||||||
brute force attacks via any rate limiting mechanism. You may either implement
|
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
|
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
|
The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
|
||||||
username and password is valid in multiple backends, Django will stop
|
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:
|
.. _auth-web-requests:
|
||||||
|
|
||||||
Authentication in Web requests
|
Authentication in web requests
|
||||||
==============================
|
==============================
|
||||||
|
|
||||||
Django uses :doc:`sessions </topics/http/sessions>` and middleware to hook the
|
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
|
When you call :func:`~django.contrib.auth.logout()`, the session data for
|
||||||
the current request is completely cleaned out. All existing data is
|
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 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
|
to put anything into the session that will be available to the user
|
||||||
immediately after logging out, do that *after* calling
|
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
|
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
|
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
|
page that your site's visitor sees. This is a lot more expensive, from a
|
||||||
processing-overhead perspective, than your standard
|
processing-overhead perspective, than your standard
|
||||||
read-a-file-off-the-filesystem server arrangement.
|
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-
|
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
|
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.
|
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
|
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
|
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
|
given a URL, try finding that page in the cache
|
||||||
if the page is 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
|
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
|
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
|
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
|
is readable and writable by the user ``apache``, or that it can be created by
|
||||||
the user ``apache``.
|
the user ``apache``.
|
||||||
|
@ -1129,7 +1129,7 @@ Downstream caches
|
||||||
=================
|
=================
|
||||||
|
|
||||||
So far, this document has focused on caching your *own* data. But another type
|
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
|
"downstream" caches. These are systems that cache pages for users even before
|
||||||
the request reaches your website.
|
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
|
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.
|
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
|
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
|
transparently. Such caching is not possible under HTTPS as it would
|
||||||
constitute a man-in-the-middle attack.
|
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
|
performance. In this case, each request first would be handled by the
|
||||||
proxy, and it would be passed to your application only if needed.
|
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
|
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.
|
again to see whether it has changed.
|
||||||
|
|
||||||
Downstream caching is a nice efficiency boost, but there's a danger to it:
|
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
|
variables, and cache systems that blindly save pages based purely on URLs could
|
||||||
expose incorrect or sensitive data to subsequent visitors to those pages.
|
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
|
"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
|
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
|
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
|
The ``Vary`` header defines which request headers a cache
|
||||||
mechanism should take into account when building its cache key. For example, if
|
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."
|
said to "vary on language."
|
||||||
|
|
||||||
By default, Django's cache system creates its cache keys using the requested
|
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
|
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
|
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
|
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.
|
private and which is public.
|
||||||
|
|
||||||
The solution is to indicate a page's cache should be "private." To do this in
|
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
|
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
|
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.
|
level.
|
||||||
|
|
||||||
Django's *generic views* were developed to ease that pain. They take certain
|
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
|
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
|
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
|
something the client has already retrieved. However, the same headers can be
|
||||||
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
|
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
|
||||||
|
|
||||||
|
|
|
@ -47,14 +47,14 @@ Create a few ``Publications``::
|
||||||
|
|
||||||
Create an ``Article``::
|
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::
|
You can't associate it with a ``Publication`` until it's been saved::
|
||||||
|
|
||||||
>>> a1.publications.add(p1)
|
>>> a1.publications.add(p1)
|
||||||
Traceback (most recent call last):
|
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!
|
Save it!
|
||||||
::
|
::
|
||||||
|
@ -100,7 +100,7 @@ Create and add a ``Publication`` to an ``Article`` in one step using
|
||||||
>>> p2.article_set.all()
|
>>> p2.article_set.all()
|
||||||
<QuerySet [<Article: NASA uses Python>]>
|
<QuerySet [<Article: NASA uses Python>]>
|
||||||
>>> p1.article_set.all()
|
>>> 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()
|
>>> Publication.objects.get(id=4).article_set.all()
|
||||||
<QuerySet [<Article: NASA uses Python>]>
|
<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>`::
|
relationships <lookups-that-span-relationships>`::
|
||||||
|
|
||||||
>>> Article.objects.filter(publications__id=1)
|
>>> 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)
|
>>> 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)
|
>>> 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)
|
>>> 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")
|
>>> Article.objects.filter(publications__title__startswith="Science")
|
||||||
<QuerySet [<Article: NASA uses Python>, <Article: NASA uses Python>]>
|
<QuerySet [<Article: NASA uses Python>, <Article: NASA uses Python>]>
|
||||||
|
@ -132,9 +132,9 @@ The :meth:`~django.db.models.query.QuerySet.count` function respects
|
||||||
1
|
1
|
||||||
|
|
||||||
>>> Article.objects.filter(publications__in=[1,2]).distinct()
|
>>> 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()
|
>>> 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
|
Reverse m2m queries are supported (i.e., starting at the table that doesn't have
|
||||||
a :class:`~django.db.models.ManyToManyField`)::
|
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)::
|
involved is a little complex)::
|
||||||
|
|
||||||
>>> Article.objects.exclude(publications=p2)
|
>>> 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::
|
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()
|
>>> a2.delete()
|
||||||
>>> Article.objects.all()
|
>>> 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()
|
>>> p2.article_set.all()
|
||||||
<QuerySet []>
|
<QuerySet []>
|
||||||
|
|
||||||
|
@ -261,7 +261,7 @@ go::
|
||||||
>>> Publication.objects.all()
|
>>> Publication.objects.all()
|
||||||
<QuerySet [<Publication: Highlights for Children>, <Publication: The Python Journal>]>
|
<QuerySet [<Publication: Highlights for Children>, <Publication: The Python Journal>]>
|
||||||
>>> Article.objects.all()
|
>>> 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()
|
>>> a2.publications.all()
|
||||||
<QuerySet [<Publication: The Python Journal>]>
|
<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')
|
>>> q = Article.objects.filter(headline__startswith='Django')
|
||||||
>>> print(q)
|
>>> print(q)
|
||||||
<QuerySet [<Article: Django lets you build Web apps easily>]>
|
<QuerySet [<Article: Django lets you build web apps easily>]>
|
||||||
>>> q.delete()
|
>>> q.delete()
|
||||||
|
|
||||||
After the :meth:`~django.db.models.query.QuerySet.delete`, the
|
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
|
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
|
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>`::
|
<queryset-model-example>`::
|
||||||
|
|
||||||
>>> entry = Entry.objects.get(id=1)
|
>>> 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;
|
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.
|
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)
|
>>> 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.
|
details of all the various model lookup options.
|
||||||
|
|
||||||
Throughout this guide (and in the reference), we'll refer to the following
|
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:
|
.. _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::
|
the number of deletions per object type. Example::
|
||||||
|
|
||||||
>>> e.delete()
|
>>> e.delete()
|
||||||
(1, {'weblog.Entry': 1})
|
(1, {'blog.Entry': 1})
|
||||||
|
|
||||||
You can also delete objects in bulk. Every
|
You can also delete objects in bulk. Every
|
||||||
:class:`~django.db.models.query.QuerySet` has a
|
: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
|
``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,
|
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,
|
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
|
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.
|
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
|
``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
|
We've described HTML forms briefly, but an HTML ``<form>`` is just one part of
|
||||||
the machinery required.
|
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
|
``<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
|
structured data returned when it is submitted, or to the end-to-end working
|
||||||
collection of these parts.
|
collection of these parts.
|
||||||
|
|
|
@ -2,11 +2,11 @@
|
||||||
Form Assets (the ``Media`` class)
|
Form Assets (the ``Media`` class)
|
||||||
=================================
|
=================================
|
||||||
|
|
||||||
Rendering an attractive and easy-to-use Web form requires more than just
|
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
|
HTML - it also requires CSS stylesheets, and if you want to use fancy widgets,
|
||||||
"Web2.0" widgets, you may also need to include some JavaScript on each
|
you may also need to include some JavaScript on each page. The exact
|
||||||
page. The exact combination of CSS and JavaScript that is required for
|
combination of CSS and JavaScript that is required for any given page will
|
||||||
any given page will depend upon the widgets that are in use on that page.
|
depend upon the widgets that are in use on that page.
|
||||||
|
|
||||||
This is where asset definitions come in. Django allows you to
|
This is where asset definitions come in. Django allows you to
|
||||||
associate different files -- like stylesheets and scripts -- with the
|
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
|
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
|
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
|
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
|
.. admonition:: Assets and Django Admin
|
||||||
|
|
||||||
|
|
|
@ -88,7 +88,7 @@ caveats:
|
||||||
so you can't define ``__init__()`` as requiring any other arguments.
|
so you can't define ``__init__()`` as requiring any other arguments.
|
||||||
|
|
||||||
* Unlike the ``__call__()`` method which is called once per request,
|
* 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
|
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
|
You might also want to set the :setting:`SESSION_FILE_PATH` setting (which
|
||||||
defaults to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to
|
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.
|
server has permissions to read and write to this location.
|
||||||
|
|
||||||
.. _cookie-session-backend:
|
.. _cookie-session-backend:
|
||||||
|
@ -264,7 +264,7 @@ You can edit it multiple times.
|
||||||
:class:`~django.contrib.sessions.serializers.PickleSerializer`.
|
:class:`~django.contrib.sessions.serializers.PickleSerializer`.
|
||||||
|
|
||||||
* If ``value`` is ``0``, the user's session cookie will expire
|
* 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
|
* If ``value`` is ``None``, the session reverts to using the global
|
||||||
session expiry policy.
|
session expiry policy.
|
||||||
|
@ -299,7 +299,7 @@ You can edit it multiple times.
|
||||||
.. method:: get_expire_at_browser_close()
|
.. method:: get_expire_at_browser_close()
|
||||||
|
|
||||||
Returns either ``True`` or ``False``, depending on whether the user's
|
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()
|
.. method:: clear_expired()
|
||||||
|
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
URL dispatcher
|
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
|
application. Django lets you design URLs however you want, with no framework
|
||||||
limitations.
|
limitations.
|
||||||
|
|
||||||
|
|
|
@ -3,8 +3,8 @@ Writing views
|
||||||
=============
|
=============
|
||||||
|
|
||||||
A view function, or *view* for short, is a Python function that takes a
|
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
|
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 .
|
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
|
. . 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
|
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
|
as it's on your Python path. There's no other requirement--no "magic," so to
|
||||||
|
@ -137,7 +137,7 @@ template.
|
||||||
Customizing error views
|
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
|
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
|
handlers as seen below in your URLconf (setting them anywhere else will have no
|
||||||
effect).
|
effect).
|
||||||
|
|
|
@ -13,7 +13,7 @@ Internationalization and localization
|
||||||
Overview
|
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
|
application to offer its content in languages and formats tailored to the
|
||||||
audience.
|
audience.
|
||||||
|
|
||||||
|
@ -25,7 +25,7 @@ Essentially, Django does two things:
|
||||||
|
|
||||||
* It allows developers and template authors to specify which parts of their apps
|
* It allows developers and template authors to specify which parts of their apps
|
||||||
should be translated or formatted for local languages and cultures.
|
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.
|
their preferences.
|
||||||
|
|
||||||
Translation depends on the target language, and formatting usually depends on
|
Translation depends on the target language, and formatting usually depends on
|
||||||
|
|
|
@ -503,7 +503,7 @@ Setup
|
||||||
datetimes, and vice-versa.
|
datetimes, and vice-versa.
|
||||||
|
|
||||||
If your application connects to other systems -- for instance, if it queries
|
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
|
datetimes safely, their representation should include the UTC offset, or
|
||||||
their values should be in UTC (or both!).
|
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
|
translators have filled in the message file, it must be compiled. This process
|
||||||
relies on the GNU gettext toolset.
|
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.
|
available language, according to users' language preferences.
|
||||||
|
|
||||||
Django's internationalization hooks are on by default, and that means there's a
|
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
|
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.
|
details.
|
||||||
|
|
||||||
Get the latest version of Python at https://www.python.org/downloads/ or with
|
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
|
life of an Apache process, which leads to significant performance
|
||||||
gains over other server arrangements. In daemon mode, mod_wsgi spawns
|
gains over other server arrangements. In daemon mode, mod_wsgi spawns
|
||||||
an independent daemon process that handles requests. The daemon
|
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
|
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
|
refreshing your codebase more seamless. Consult the mod_wsgi
|
||||||
documentation to determine which mode is right for your setup. Make
|
documentation to determine which mode is right for your setup. Make
|
||||||
sure you have Apache installed with the mod_wsgi module activated.
|
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