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():
|
||||
...
|
||||
|
||||
.. admonition:: When using mutiple decorators
|
||||
.. admonition:: When using multiple decorators
|
||||
|
||||
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
|
||||
mutiple decorators, then make sure to place ``@sensitive_variables`` at
|
||||
the top of the decorator chain. This way it will also hide the function
|
||||
argument as it gets passed through the other decorators::
|
||||
multiple decorators, then make sure to place ``@sensitive_variables``
|
||||
at the top of the decorator chain. This way it will also hide the
|
||||
function argument as it gets passed through the other decorators::
|
||||
|
||||
@sensitive_variables('user', 'pw', 'cc')
|
||||
@some_decorator
|
||||
|
|
|
@ -414,9 +414,9 @@ Anssi Kääriäinen
|
|||
Florian Apolloner
|
||||
Florian is currently studying Physics at the `Graz University of Technology`_.
|
||||
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/
|
||||
.. _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
|
||||
deprecated as part of the 1.3 release. An accelerated deprecation
|
||||
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``.
|
||||
|
||||
* 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.
|
||||
|
||||
#. 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
|
||||
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,
|
||||
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
|
||||
whathaveyou.
|
||||
whatever you need.
|
||||
|
||||
* If you are interested in deploying a project for public use, our docs have
|
||||
: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
|
||||
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.
|
||||
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 []
|
||||
|
||||
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:
|
||||
the only difference is that the check is a classmethod, not an instance method::
|
||||
|
|
|
@ -91,7 +91,7 @@ MultipleObjectMixin
|
|||
.. attribute:: page_kwarg
|
||||
|
||||
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
|
||||
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
|
||||
just after the object and all the related instances have
|
||||
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)
|
||||
|
||||
|
|
|
@ -726,7 +726,7 @@ sessions and browser cookies respectively).
|
|||
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
|
||||
"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
|
||||
:meth:`~WizardView.as_view` method:
|
||||
|
|
|
@ -158,7 +158,7 @@ Widget classes
|
|||
|
||||
``OpenLayersWidget`` and :class:`OSMWidget` use the ``openlayers.js`` file
|
||||
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.
|
||||
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
|
||||
|
|
|
@ -7,7 +7,7 @@ GDAL API
|
|||
.. module:: django.contrib.gis.gdal
|
||||
: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
|
||||
of GDAL is the `OGR`__ Simple Features Library, which specializes
|
||||
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
|
||||
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
|
||||
(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
|
||||
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
|
||||
dissolving boundaries.
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ Background
|
|||
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
|
||||
implements the OpenGIS `Simple Features for SQL`__ spatial predicate functions
|
||||
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
|
||||
|
||||
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()
|
||||
|
||||
|
@ -625,7 +625,7 @@ is returned instead.
|
|||
.. classmethod:: from_bbox(bbox)
|
||||
|
||||
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
|
||||
|
||||
|
|
|
@ -116,7 +116,7 @@ Keyword Arguments
|
|||
(defaults to 0)
|
||||
|
||||
``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
|
||||
:class:`django.contrib.gis.gdal.SpatialReference`
|
||||
objects are accepted.
|
||||
|
|
|
@ -123,7 +123,7 @@ calculations.
|
|||
|
||||
.. 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
|
||||
better performance, enable the :attr:`GeometryField.geography`
|
||||
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
|
||||
direction. Pass ``--backwards`` to generate the SQL for
|
||||
un-applying the migration instead.
|
||||
unapplying the migration instead.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
.. currentmodule:: django.core.urlresolvers
|
||||
|
|
|
@ -233,8 +233,8 @@ to this API.
|
|||
execute the query.
|
||||
|
||||
Calling expression.as_sql() directly is usually incorrect - instead
|
||||
qn.compile(expression) should be used. The qn.compile() method will take
|
||||
care of calling vendor-specific methods of the expression.
|
||||
``qn.compile(expression)`` should be used. The ``qn.compile()`` method will
|
||||
take care of calling vendor-specific methods of the expression.
|
||||
|
||||
.. method:: get_lookup(lookup_name)
|
||||
|
||||
|
|
|
@ -1785,7 +1785,7 @@ See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
|||
SIGNING_BACKEND
|
||||
---------------
|
||||
|
||||
Default: 'django.core.signing.TimestampSigner'
|
||||
Default: ``'django.core.signing.TimestampSigner'``
|
||||
|
||||
The backend used for signing cookies and other data.
|
||||
|
||||
|
|
|
@ -611,7 +611,7 @@ request_finished
|
|||
.. data:: django.core.signals.request_finished
|
||||
:module:
|
||||
|
||||
Sent when Django finishes delvering an HTTP response to the client.
|
||||
Sent when Django finishes delivering an HTTP response to the client.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
@ -87,7 +87,7 @@ Introduction of STATIC_URL and STATIC_ROOT settings
|
|||
|
||||
The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
|
||||
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`
|
||||
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,
|
||||
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.
|
||||
* 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,
|
||||
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.
|
||||
* Port, if specified, is numeric.
|
||||
|
|
|
@ -1120,7 +1120,7 @@ Miscellaneous
|
|||
primary keys with value 0.
|
||||
|
||||
* 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.
|
||||
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.
|
||||
|
|
|
@ -569,7 +569,7 @@ The following methods are available on any subclass of
|
|||
.. versionchanged:: 1.6
|
||||
|
||||
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)
|
||||
|
||||
|
|
|
@ -10,9 +10,9 @@ processing-overhead perspective, than your standard
|
|||
read-a-file-off-the-filesystem server arrangement.
|
||||
|
||||
For most Web applications, this overhead isn't a big deal. Most Web
|
||||
applications aren't washingtonpost.com or slashdot.org; they're simply small-
|
||||
to medium-sized sites with so-so traffic. But for medium- to high-traffic
|
||||
sites, it's essential to cut as much overhead as possible.
|
||||
applications aren't ``washingtonpost.com`` or ``slashdot.org``; they're simply
|
||||
small- to medium-sized sites with so-so traffic. But for medium- to
|
||||
high-traffic sites, it's essential to cut as much overhead as possible.
|
||||
|
||||
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
|
||||
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
|
||||
memory cache, you will need to assign a name to at least one of them in
|
||||
order to keep them separate.
|
||||
|
@ -470,7 +470,7 @@ Additionally, the cache middleware automatically sets a few headers in each
|
|||
:class:`~django.http.HttpResponse`:
|
||||
|
||||
* 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
|
||||
: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
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -201,7 +201,7 @@ __ http://en.wikipedia.org/wiki/SQL_injection
|
|||
|
||||
In Django 1.5 and earlier, you could pass parameters as dictionaries
|
||||
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:
|
||||
|
|
|
@ -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.
|
||||
|
||||
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
|
||||
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
|
||||
explicitly anywhere inside a view. Since :setting:`ATOMIC_REQUESTS
|
||||
<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
|
||||
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 |
|
||||
+==================+===============+=========================================+
|
||||
| Unsubmitted | None yet | Template gets passed unbound instance |
|
||||
| Not submitted | None yet | Template gets passed unbound instance |
|
||||
| | | of ContactForm. |
|
||||
+------------------+---------------+-----------------------------------------+
|
||||
| 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"
|
||||
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
|
||||
that your site publishes.
|
||||
|
||||
|
|
|
@ -1255,7 +1255,7 @@ your test suite.
|
|||
:param empty_value: the expected clean output for inputs in ``empty_values``.
|
||||
|
||||
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::
|
||||
|
||||
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
|
||||
:meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
|
||||
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.
|
||||
|
||||
Output in case of error can be customized with the ``msg`` argument.
|
||||
|
|
Loading…
Reference in New Issue