mirror of https://github.com/django/django.git
Fixed docs typos.
This commit is contained in:
parent
65b4626528
commit
e816198034
|
@ -163,13 +163,13 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
|
||||||
def my_function():
|
def my_function():
|
||||||
...
|
...
|
||||||
|
|
||||||
.. admonition:: When using mutiple decorators
|
.. admonition:: When using multiple decorators
|
||||||
|
|
||||||
If the variable you want to hide is also a function argument (e.g.
|
If the variable you want to hide is also a function argument (e.g.
|
||||||
'``user``’ in the following example), and if the decorated function has
|
'``user``’ in the following example), and if the decorated function has
|
||||||
mutiple decorators, then make sure to place ``@sensitive_variables`` at
|
multiple decorators, then make sure to place ``@sensitive_variables``
|
||||||
the top of the decorator chain. This way it will also hide the function
|
at the top of the decorator chain. This way it will also hide the
|
||||||
argument as it gets passed through the other decorators::
|
function argument as it gets passed through the other decorators::
|
||||||
|
|
||||||
@sensitive_variables('user', 'pw', 'cc')
|
@sensitive_variables('user', 'pw', 'cc')
|
||||||
@some_decorator
|
@some_decorator
|
||||||
|
|
|
@ -414,9 +414,9 @@ Anssi Kääriäinen
|
||||||
Florian Apolloner
|
Florian Apolloner
|
||||||
Florian is currently studying Physics at the `Graz University of Technology`_.
|
Florian is currently studying Physics at the `Graz University of Technology`_.
|
||||||
Soon after he started using Django he joined the `Ubuntuusers webteam`_ to
|
Soon after he started using Django he joined the `Ubuntuusers webteam`_ to
|
||||||
work on *Inyoka*, the software powering the whole Ubuntusers site.
|
work on *Inyoka*, the software powering the whole Ubuntuusers site.
|
||||||
|
|
||||||
For the time beeing he lives in Graz, Austria (not Australia ;)).
|
For the time being he lives in Graz, Austria (not Australia ;)).
|
||||||
|
|
||||||
.. _Graz University of Technology: http://tugraz.at/
|
.. _Graz University of Technology: http://tugraz.at/
|
||||||
.. _Ubuntuusers webteam: http://wiki.ubuntuusers.de/ubuntuusers/Webteam
|
.. _Ubuntuusers webteam: http://wiki.ubuntuusers.de/ubuntuusers/Webteam
|
||||||
|
|
|
@ -537,7 +537,7 @@ details on these changes.
|
||||||
* ``django.db.models.fields.XMLField`` will be removed. This was
|
* ``django.db.models.fields.XMLField`` will be removed. This was
|
||||||
deprecated as part of the 1.3 release. An accelerated deprecation
|
deprecated as part of the 1.3 release. An accelerated deprecation
|
||||||
schedule has been used because the field hasn't performed any role
|
schedule has been used because the field hasn't performed any role
|
||||||
beyond that of a simple ``TextField`` since the removal of oldforms.
|
beyond that of a simple ``TextField`` since the removal of ``oldforms``.
|
||||||
All uses of ``XMLField`` can be replaced with ``TextField``.
|
All uses of ``XMLField`` can be replaced with ``TextField``.
|
||||||
|
|
||||||
* The undocumented ``mixin`` parameter to the ``open()`` method of
|
* The undocumented ``mixin`` parameter to the ``open()`` method of
|
||||||
|
|
|
@ -100,7 +100,7 @@ any time leading up to the actual release:
|
||||||
are left for the upcoming release.
|
are left for the upcoming release.
|
||||||
|
|
||||||
#. Check with the other committers to make sure they don't have any
|
#. Check with the other committers to make sure they don't have any
|
||||||
un-committed changes for the release.
|
uncommitted changes for the release.
|
||||||
|
|
||||||
#. Proofread the release notes, including looking at the online
|
#. Proofread the release notes, including looking at the online
|
||||||
version to catch any broken links or reST errors, and make sure the
|
version to catch any broken links or reST errors, and make sure the
|
||||||
|
|
|
@ -64,7 +64,7 @@ different needs:
|
||||||
trying to learn. Instead, details about individual classes, functions,
|
trying to learn. Instead, details about individual classes, functions,
|
||||||
methods, and modules are kept in the :doc:`reference </ref/index>`. This is
|
methods, and modules are kept in the :doc:`reference </ref/index>`. This is
|
||||||
where you'll turn to find the details of a particular function or
|
where you'll turn to find the details of a particular function or
|
||||||
whathaveyou.
|
whatever you need.
|
||||||
|
|
||||||
* If you are interested in deploying a project for public use, our docs have
|
* If you are interested in deploying a project for public use, our docs have
|
||||||
:doc:`several guides</howto/deployment/index>` for various deployment
|
:doc:`several guides</howto/deployment/index>` for various deployment
|
||||||
|
|
|
@ -150,7 +150,7 @@ piggyback on an existing registration.
|
||||||
|
|
||||||
Fields, models, and model managers all implement a ``check()`` method that is
|
Fields, models, and model managers all implement a ``check()`` method that is
|
||||||
already registered with the check framework. If you want to add extra checks,
|
already registered with the check framework. If you want to add extra checks,
|
||||||
you can extend the implemenation on the base class, perform any extra
|
you can extend the implementation on the base class, perform any extra
|
||||||
checks you need, and append any messages to those generated by the base class.
|
checks you need, and append any messages to those generated by the base class.
|
||||||
It's recommended the you delegate each check to a separate methods.
|
It's recommended the you delegate each check to a separate methods.
|
||||||
|
|
||||||
|
@ -195,7 +195,7 @@ code snippet shows how you can implement this check::
|
||||||
return []
|
return []
|
||||||
|
|
||||||
If you wanted to add checks to a model manager, you would take the same
|
If you wanted to add checks to a model manager, you would take the same
|
||||||
approach on your sublass of :class:`~django.db.models.Manager`.
|
approach on your subclass of :class:`~django.db.models.Manager`.
|
||||||
|
|
||||||
If you want to add a check to a model class, the approach is *almost* the same:
|
If you want to add a check to a model class, the approach is *almost* the same:
|
||||||
the only difference is that the check is a classmethod, not an instance method::
|
the only difference is that the check is a classmethod, not an instance method::
|
||||||
|
|
|
@ -91,7 +91,7 @@ MultipleObjectMixin
|
||||||
.. attribute:: page_kwarg
|
.. attribute:: page_kwarg
|
||||||
|
|
||||||
A string specifying the name to use for the page parameter.
|
A string specifying the name to use for the page parameter.
|
||||||
The view will expect this prameter to be available either as a query
|
The view will expect this parameter to be available either as a query
|
||||||
string parameter (via ``request.GET``) or as a kwarg variable specified
|
string parameter (via ``request.GET``) or as a kwarg variable specified
|
||||||
in the URLconf. Defaults to ``page``.
|
in the URLconf. Defaults to ``page``.
|
||||||
|
|
||||||
|
|
|
@ -1693,7 +1693,7 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
``response_change`` is called after the admin form is submitted and
|
``response_change`` is called after the admin form is submitted and
|
||||||
just after the object and all the related instances have
|
just after the object and all the related instances have
|
||||||
been saved. You can override it to change the default
|
been saved. You can override it to change the default
|
||||||
behavior after the object has been changedn.
|
behavior after the object has been changed.
|
||||||
|
|
||||||
.. method:: ModelAdmin.response_delete(request, obj_display)
|
.. method:: ModelAdmin.response_delete(request, obj_display)
|
||||||
|
|
||||||
|
|
|
@ -726,7 +726,7 @@ sessions and browser cookies respectively).
|
||||||
To use the named urls, you have to change the ``urls.py``.
|
To use the named urls, you have to change the ``urls.py``.
|
||||||
|
|
||||||
Below you will see an example of a contact wizard with two steps, step 1 with
|
Below you will see an example of a contact wizard with two steps, step 1 with
|
||||||
"contactdata" as its name and step 2 with "leavemessage" as its name.
|
``"contactdata"`` as its name and step 2 with ``"leavemessage"`` as its name.
|
||||||
|
|
||||||
Additionally you have to pass two more arguments to the
|
Additionally you have to pass two more arguments to the
|
||||||
:meth:`~WizardView.as_view` method:
|
:meth:`~WizardView.as_view` method:
|
||||||
|
|
|
@ -158,7 +158,7 @@ Widget classes
|
||||||
|
|
||||||
``OpenLayersWidget`` and :class:`OSMWidget` use the ``openlayers.js`` file
|
``OpenLayersWidget`` and :class:`OSMWidget` use the ``openlayers.js`` file
|
||||||
hosted on the ``openlayers.org`` Web site. This works for basic usage
|
hosted on the ``openlayers.org`` Web site. This works for basic usage
|
||||||
during development, but isn't appropropriate for a production deployment as
|
during development, but isn't appropriate for a production deployment as
|
||||||
``openlayers.org/api/`` has no guaranteed uptime and runs on a slow server.
|
``openlayers.org/api/`` has no guaranteed uptime and runs on a slow server.
|
||||||
You are therefore advised to subclass these widgets in order to specify
|
You are therefore advised to subclass these widgets in order to specify
|
||||||
your own version of the ``openlayers.js`` file in the ``js`` property of
|
your own version of the ``openlayers.js`` file in the ``js`` property of
|
||||||
|
|
|
@ -7,7 +7,7 @@ GDAL API
|
||||||
.. module:: django.contrib.gis.gdal
|
.. module:: django.contrib.gis.gdal
|
||||||
:synopsis: GeoDjango's high-level interface to the GDAL library.
|
:synopsis: GeoDjango's high-level interface to the GDAL library.
|
||||||
|
|
||||||
`GDAL`__ stands for **G**\ eospatial **D**\ ata **A**\ bstraction **L**\ ibrary,
|
`GDAL`__ stands for **Geospatial Data Abstraction Library**,
|
||||||
and is a veritable "swiss army knife" of GIS data functionality. A subset
|
and is a veritable "swiss army knife" of GIS data functionality. A subset
|
||||||
of GDAL is the `OGR`__ Simple Features Library, which specializes
|
of GDAL is the `OGR`__ Simple Features Library, which specializes
|
||||||
in reading and writing vector geographic data in a variety of standard
|
in reading and writing vector geographic data in a variety of standard
|
||||||
|
|
|
@ -638,7 +638,7 @@ Oracle ``SDO_WITHIN_DISTANCE(poly, geom, 5)``
|
||||||
=======================
|
=======================
|
||||||
|
|
||||||
``GeoQuerySet`` methods specify that a spatial operation be performed
|
``GeoQuerySet`` methods specify that a spatial operation be performed
|
||||||
on each patial operation on each geographic
|
on each spatial operation on each geographic
|
||||||
field in the queryset and store its output in a new attribute on the model
|
field in the queryset and store its output in a new attribute on the model
|
||||||
(which is generally the name of the ``GeoQuerySet`` method).
|
(which is generally the name of the ``GeoQuerySet`` method).
|
||||||
|
|
||||||
|
@ -1103,7 +1103,7 @@ Aggregate Methods
|
||||||
|
|
||||||
Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry
|
Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry
|
||||||
column. This is analagous to a simplified version of the :meth:`GeoQuerySet.unionagg` method,
|
column. This is analagous to a simplified version of the :meth:`GeoQuerySet.unionagg` method,
|
||||||
except it can be several orders of magnitude faster than peforming a union because
|
except it can be several orders of magnitude faster than performing a union because
|
||||||
it simply rolls up geometries into a collection or multi object, not caring about
|
it simply rolls up geometries into a collection or multi object, not caring about
|
||||||
dissolving boundaries.
|
dissolving boundaries.
|
||||||
|
|
||||||
|
|
|
@ -13,7 +13,7 @@ Background
|
||||||
What is GEOS?
|
What is GEOS?
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
`GEOS`__ stands for **G**\ eometry **E**\ ngine - **O**\ pen **S**\ ource,
|
`GEOS`__ stands for **Geometry Engine - Open Source**,
|
||||||
and is a C++ library, ported from the `Java Topology Suite`__. GEOS
|
and is a C++ library, ported from the `Java Topology Suite`__. GEOS
|
||||||
implements the OpenGIS `Simple Features for SQL`__ spatial predicate functions
|
implements the OpenGIS `Simple Features for SQL`__ spatial predicate functions
|
||||||
and spatial operators. GEOS, now an OSGeo project, was initially developed and
|
and spatial operators. GEOS, now an OSGeo project, was initially developed and
|
||||||
|
@ -500,7 +500,7 @@ This property returns the area of the Geometry.
|
||||||
.. attribute:: GEOSGeometry.extent
|
.. attribute:: GEOSGeometry.extent
|
||||||
|
|
||||||
This property returns the extent of this geometry as a 4-tuple,
|
This property returns the extent of this geometry as a 4-tuple,
|
||||||
consisting of (xmin, ymin, xmax, ymax).
|
consisting of ``(xmin, ymin, xmax, ymax)``.
|
||||||
|
|
||||||
.. method:: GEOSGeometry.clone()
|
.. method:: GEOSGeometry.clone()
|
||||||
|
|
||||||
|
@ -625,7 +625,7 @@ is returned instead.
|
||||||
.. classmethod:: from_bbox(bbox)
|
.. classmethod:: from_bbox(bbox)
|
||||||
|
|
||||||
Returns a polygon object from the given bounding-box, a 4-tuple
|
Returns a polygon object from the given bounding-box, a 4-tuple
|
||||||
comprising (xmin, ymin, xmax, ymax).
|
comprising ``(xmin, ymin, xmax, ymax)``.
|
||||||
|
|
||||||
.. attribute:: num_interior_rings
|
.. attribute:: num_interior_rings
|
||||||
|
|
||||||
|
|
|
@ -116,7 +116,7 @@ Keyword Arguments
|
||||||
(defaults to 0)
|
(defaults to 0)
|
||||||
|
|
||||||
``source_srs`` Use this to specify the source SRS manually (for
|
``source_srs`` Use this to specify the source SRS manually (for
|
||||||
example, some shapefiles don't come with a '.prj'
|
example, some shapefiles don't come with a ``'.prj'``
|
||||||
file). An integer SRID, WKT or PROJ.4 strings, and
|
file). An integer SRID, WKT or PROJ.4 strings, and
|
||||||
:class:`django.contrib.gis.gdal.SpatialReference`
|
:class:`django.contrib.gis.gdal.SpatialReference`
|
||||||
objects are accepted.
|
objects are accepted.
|
||||||
|
|
|
@ -123,7 +123,7 @@ calculations.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If you wish to peform arbitrary distance queries using non-point
|
If you wish to perform arbitrary distance queries using non-point
|
||||||
geometries in WGS84, consider upgrading to PostGIS 1.5. For
|
geometries in WGS84, consider upgrading to PostGIS 1.5. For
|
||||||
better performance, enable the :attr:`GeometryField.geography`
|
better performance, enable the :attr:`GeometryField.geography`
|
||||||
keyword so that :ref:`geography database type <geography-type>`
|
keyword so that :ref:`geography database type <geography-type>`
|
||||||
|
|
|
@ -1082,7 +1082,7 @@ which to generate the SQL.
|
||||||
|
|
||||||
By default, the SQL created is for running the migration in the forwards
|
By default, the SQL created is for running the migration in the forwards
|
||||||
direction. Pass ``--backwards`` to generate the SQL for
|
direction. Pass ``--backwards`` to generate the SQL for
|
||||||
un-applying the migration instead.
|
unapplying the migration instead.
|
||||||
|
|
||||||
sqlsequencereset <app_label app_label ...>
|
sqlsequencereset <app_label app_label ...>
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
|
|
|
@ -130,7 +130,7 @@ NON_FIELD_ERRORS
|
||||||
|
|
||||||
``ValidationError``\s that don't belong to a particular field in a form
|
``ValidationError``\s that don't belong to a particular field in a form
|
||||||
or model are classified as ``NON_FIELD_ERRORS``. This constant is used
|
or model are classified as ``NON_FIELD_ERRORS``. This constant is used
|
||||||
as a key in dictonaries that otherwise map fields to their respective
|
as a key in dictionaries that otherwise map fields to their respective
|
||||||
list of errors.
|
list of errors.
|
||||||
|
|
||||||
.. currentmodule:: django.core.urlresolvers
|
.. currentmodule:: django.core.urlresolvers
|
||||||
|
|
|
@ -233,8 +233,8 @@ to this API.
|
||||||
execute the query.
|
execute the query.
|
||||||
|
|
||||||
Calling expression.as_sql() directly is usually incorrect - instead
|
Calling expression.as_sql() directly is usually incorrect - instead
|
||||||
qn.compile(expression) should be used. The qn.compile() method will take
|
``qn.compile(expression)`` should be used. The ``qn.compile()`` method will
|
||||||
care of calling vendor-specific methods of the expression.
|
take care of calling vendor-specific methods of the expression.
|
||||||
|
|
||||||
.. method:: get_lookup(lookup_name)
|
.. method:: get_lookup(lookup_name)
|
||||||
|
|
||||||
|
|
|
@ -1785,7 +1785,7 @@ See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
||||||
SIGNING_BACKEND
|
SIGNING_BACKEND
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Default: 'django.core.signing.TimestampSigner'
|
Default: ``'django.core.signing.TimestampSigner'``
|
||||||
|
|
||||||
The backend used for signing cookies and other data.
|
The backend used for signing cookies and other data.
|
||||||
|
|
||||||
|
|
|
@ -611,7 +611,7 @@ request_finished
|
||||||
.. data:: django.core.signals.request_finished
|
.. data:: django.core.signals.request_finished
|
||||||
:module:
|
:module:
|
||||||
|
|
||||||
Sent when Django finishes delvering an HTTP response to the client.
|
Sent when Django finishes delivering an HTTP response to the client.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
|
|
|
@ -87,7 +87,7 @@ Introduction of STATIC_URL and STATIC_ROOT settings
|
||||||
|
|
||||||
The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
|
The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
|
||||||
Django's abilities to handle static files for apps and projects -- required the
|
Django's abilities to handle static files for apps and projects -- required the
|
||||||
additon of two new settings to refer to those files in templates and code,
|
addition of two new settings to refer to those files in templates and code,
|
||||||
especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
|
especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
|
||||||
settings that refer to user-uploaded files.
|
settings that refer to user-uploaded files.
|
||||||
|
|
||||||
|
|
|
@ -26,7 +26,7 @@ header validation. Rather than attempt to accommodate all features HTTP
|
||||||
supports here, Django's Host header validation attempts to support a smaller,
|
supports here, Django's Host header validation attempts to support a smaller,
|
||||||
but far more common, subset:
|
but far more common, subset:
|
||||||
|
|
||||||
* Hostnames must consist of characters [A-Za-z0-9] plus hyphen ('-') or dot
|
* Hostnames must consist of characters ``[A-Za-z0-9]`` plus hyphen ('-') or dot
|
||||||
('.').
|
('.').
|
||||||
* IP addresses -- both IPv4 and IPv6 -- are permitted.
|
* IP addresses -- both IPv4 and IPv6 -- are permitted.
|
||||||
* Port, if specified, is numeric.
|
* Port, if specified, is numeric.
|
||||||
|
|
|
@ -26,7 +26,7 @@ header validation. Rather than attempt to accommodate all features HTTP
|
||||||
supports here, Django's Host header validation attempts to support a smaller,
|
supports here, Django's Host header validation attempts to support a smaller,
|
||||||
but far more common, subset:
|
but far more common, subset:
|
||||||
|
|
||||||
* Hostnames must consist of characters [A-Za-z0-9] plus hyphen ('-') or dot
|
* Hostnames must consist of characters ``[A-Za-z0-9]`` plus hyphen ('-') or dot
|
||||||
('.').
|
('.').
|
||||||
* IP addresses -- both IPv4 and IPv6 -- are permitted.
|
* IP addresses -- both IPv4 and IPv6 -- are permitted.
|
||||||
* Port, if specified, is numeric.
|
* Port, if specified, is numeric.
|
||||||
|
|
|
@ -1120,7 +1120,7 @@ Miscellaneous
|
||||||
primary keys with value 0.
|
primary keys with value 0.
|
||||||
|
|
||||||
* Shadowing model fields defined in a parent model has been forbidden as this
|
* Shadowing model fields defined in a parent model has been forbidden as this
|
||||||
creates amiguity in the expected model behavior. In addition, any clashing
|
creates ambiguity in the expected model behavior. In addition, any clashing
|
||||||
fields in the model inheritance hierarchy results in a system check error.
|
fields in the model inheritance hierarchy results in a system check error.
|
||||||
For example, if you use multi-inheritance, you need to define custom primary
|
For example, if you use multi-inheritance, you need to define custom primary
|
||||||
key fields on parent models, otherwise the default ``id`` fields will clash.
|
key fields on parent models, otherwise the default ``id`` fields will clash.
|
||||||
|
|
|
@ -569,7 +569,7 @@ The following methods are available on any subclass of
|
||||||
.. versionchanged:: 1.6
|
.. versionchanged:: 1.6
|
||||||
|
|
||||||
In Django 1.4 and 1.5, a blank string was unintentionally stored
|
In Django 1.4 and 1.5, a blank string was unintentionally stored
|
||||||
as an unsable password as well.
|
as an unusable password as well.
|
||||||
|
|
||||||
.. method:: models.AbstractBaseUser.check_password(raw_password)
|
.. method:: models.AbstractBaseUser.check_password(raw_password)
|
||||||
|
|
||||||
|
|
|
@ -10,9 +10,9 @@ 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 simply small-
|
applications aren't ``washingtonpost.com`` or ``slashdot.org``; they're simply
|
||||||
to medium-sized sites with so-so traffic. But for medium- to high-traffic
|
small- to medium-sized sites with so-so traffic. But for medium- to
|
||||||
sites, it's essential to cut as much overhead as possible.
|
high-traffic sites, it's essential to cut as much overhead as possible.
|
||||||
|
|
||||||
That's where caching comes in.
|
That's where caching comes in.
|
||||||
|
|
||||||
|
@ -307,7 +307,7 @@ to ``"django.core.cache.backends.locmem.LocMemCache"``. For example::
|
||||||
}
|
}
|
||||||
|
|
||||||
The cache :setting:`LOCATION <CACHES-LOCATION>` is used to identify individual
|
The cache :setting:`LOCATION <CACHES-LOCATION>` is used to identify individual
|
||||||
memory stores. If you only have one locmem cache, you can omit the
|
memory stores. If you only have one ``locmem`` cache, you can omit the
|
||||||
:setting:`LOCATION <CACHES-LOCATION>`; however, if you have more than one local
|
:setting:`LOCATION <CACHES-LOCATION>`; however, if you have more than one local
|
||||||
memory cache, you will need to assign a name to at least one of them in
|
memory cache, you will need to assign a name to at least one of them in
|
||||||
order to keep them separate.
|
order to keep them separate.
|
||||||
|
@ -470,7 +470,7 @@ Additionally, the cache middleware automatically sets a few headers in each
|
||||||
:class:`~django.http.HttpResponse`:
|
:class:`~django.http.HttpResponse`:
|
||||||
|
|
||||||
* Sets the ``Last-Modified`` header to the current date/time when a fresh
|
* Sets the ``Last-Modified`` header to the current date/time when a fresh
|
||||||
(uncached) version of the page is requested.
|
(not cached) version of the page is requested.
|
||||||
|
|
||||||
* Sets the ``Expires`` header to the current date/time plus the defined
|
* Sets the ``Expires`` header to the current date/time plus the defined
|
||||||
:setting:`CACHE_MIDDLEWARE_SECONDS`.
|
:setting:`CACHE_MIDDLEWARE_SECONDS`.
|
||||||
|
|
|
@ -1022,7 +1022,8 @@ of the model name::
|
||||||
|
|
||||||
However, if ``p`` in the above example was *not* a ``Restaurant`` (it had been
|
However, if ``p`` in the above example was *not* a ``Restaurant`` (it had been
|
||||||
created directly as a ``Place`` object or was the parent of some other class),
|
created directly as a ``Place`` object or was the parent of some other class),
|
||||||
referring to ``p.restaurant`` would raise a Restaurant.DoesNotExist exception.
|
referring to ``p.restaurant`` would raise a ``Restaurant.DoesNotExist``
|
||||||
|
exception.
|
||||||
|
|
||||||
``Meta`` and multi-table inheritance
|
``Meta`` and multi-table inheritance
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -201,7 +201,7 @@ __ http://en.wikipedia.org/wiki/SQL_injection
|
||||||
|
|
||||||
In Django 1.5 and earlier, you could pass parameters as dictionaries
|
In Django 1.5 and earlier, you could pass parameters as dictionaries
|
||||||
when using PostgreSQL or MySQL, although this wasn't documented. Now
|
when using PostgreSQL or MySQL, although this wasn't documented. Now
|
||||||
you can also do this whem using Oracle, and it is officially supported.
|
you can also do this when using Oracle, and it is officially supported.
|
||||||
|
|
||||||
|
|
||||||
.. _executing-custom-sql:
|
.. _executing-custom-sql:
|
||||||
|
|
|
@ -44,7 +44,7 @@ transaction. If the response is produced without problems, Django commits the
|
||||||
transaction. If the view produces an exception, Django rolls back the
|
transaction. If the view produces an exception, Django rolls back the
|
||||||
transaction.
|
transaction.
|
||||||
|
|
||||||
You may perfom partial commits and rollbacks in your view code, typically with
|
You may perform partial commits and rollbacks in your view code, typically with
|
||||||
the :func:`atomic` context manager. However, at the end of the view, either
|
the :func:`atomic` context manager. However, at the end of the view, either
|
||||||
all the changes will be committed, or none of them.
|
all the changes will be committed, or none of them.
|
||||||
|
|
||||||
|
@ -622,7 +622,7 @@ behavior is the same, there are two differences.
|
||||||
With the previous API, it was possible to switch to autocommit or to commit
|
With the previous API, it was possible to switch to autocommit or to commit
|
||||||
explicitly anywhere inside a view. Since :setting:`ATOMIC_REQUESTS
|
explicitly anywhere inside a view. Since :setting:`ATOMIC_REQUESTS
|
||||||
<DATABASE-ATOMIC_REQUESTS>` relies on :func:`atomic` which enforces atomicity,
|
<DATABASE-ATOMIC_REQUESTS>` relies on :func:`atomic` which enforces atomicity,
|
||||||
this isn't allowed any longer. However, at the toplevel, it's still possible
|
this isn't allowed any longer. However, at the top level, it's still possible
|
||||||
to avoid wrapping an entire view in a transaction. To achieve this, decorate
|
to avoid wrapping an entire view in a transaction. To achieve this, decorate
|
||||||
the view with :func:`non_atomic_requests` instead of :func:`autocommit`.
|
the view with :func:`non_atomic_requests` instead of :func:`autocommit`.
|
||||||
|
|
||||||
|
|
|
@ -115,7 +115,7 @@ There are three possible code paths here:
|
||||||
+------------------+---------------+-----------------------------------------+
|
+------------------+---------------+-----------------------------------------+
|
||||||
| Form submitted? | Data? | What occurs |
|
| Form submitted? | Data? | What occurs |
|
||||||
+==================+===============+=========================================+
|
+==================+===============+=========================================+
|
||||||
| Unsubmitted | None yet | Template gets passed unbound instance |
|
| Not submitted | None yet | Template gets passed unbound instance |
|
||||||
| | | of ContactForm. |
|
| | | of ContactForm. |
|
||||||
+------------------+---------------+-----------------------------------------+
|
+------------------+---------------+-----------------------------------------+
|
||||||
| Submitted | Invalid data | Template gets passed bound instance |
|
| Submitted | Invalid data | Template gets passed bound instance |
|
||||||
|
|
|
@ -305,7 +305,7 @@ tag, so browsers will reload the asset automatically.
|
||||||
^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Several third-party Django tools and packages provide the ability to "minify"
|
Several third-party Django tools and packages provide the ability to "minify"
|
||||||
HTML, CSS, and JavaScript. They remove uneccessary whitespace, newlines, and
|
HTML, CSS, and JavaScript. They remove unnecessary whitespace, newlines, and
|
||||||
comments, and shorten variable names, and thus reduce the size of the documents
|
comments, and shorten variable names, and thus reduce the size of the documents
|
||||||
that your site publishes.
|
that your site publishes.
|
||||||
|
|
||||||
|
|
|
@ -1255,7 +1255,7 @@ your test suite.
|
||||||
:param empty_value: the expected clean output for inputs in ``empty_values``.
|
:param empty_value: the expected clean output for inputs in ``empty_values``.
|
||||||
|
|
||||||
For example, the following code tests that an ``EmailField`` accepts
|
For example, the following code tests that an ``EmailField`` accepts
|
||||||
"a@a.com" as a valid email address, but rejects "aaa" with a reasonable
|
``a@a.com`` as a valid email address, but rejects ``aaa`` with a reasonable
|
||||||
error message::
|
error message::
|
||||||
|
|
||||||
self.assertFieldOutput(EmailField, {'a@a.com': 'a@a.com'}, {'aaa': [u'Enter a valid email address.']})
|
self.assertFieldOutput(EmailField, {'a@a.com': 'a@a.com'}, {'aaa': [u'Enter a valid email address.']})
|
||||||
|
@ -1412,7 +1412,7 @@ your test suite.
|
||||||
comparison is based on XML semantics. Similarly to
|
comparison is based on XML semantics. Similarly to
|
||||||
:meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
|
:meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
|
||||||
made on parsed content, hence only semantic differences are considered, not
|
made on parsed content, hence only semantic differences are considered, not
|
||||||
syntax differences. When unvalid XML is passed in any parameter, an
|
syntax differences. When invalid XML is passed in any parameter, an
|
||||||
``AssertionError`` is always raised, even if both string are identical.
|
``AssertionError`` is always raised, even if both string are identical.
|
||||||
|
|
||||||
Output in case of error can be customized with the ``msg`` argument.
|
Output in case of error can be customized with the ``msg`` argument.
|
||||||
|
|
Loading…
Reference in New Issue