Author: adrian
Date: 2012-02-17 12:04:11 -0800 (Fri, 17 Feb 2012)
New Revision: 17540
Modified:
django/trunk/django/core/management/validation.py
django/trunk/django/middleware/csrf.py
django/trunk/docs/howto/custom-management-commands.txt
django/trunk/docs/ref/contrib/admin/index.txt
django/trunk/docs/ref/contrib/gis/install.txt
django/trunk/docs/ref/contrib/gis/testing.txt
django/trunk/docs/ref/django-admin.txt
django/trunk/docs/ref/settings.txt
django/trunk/docs/releases/1.4.txt
django/trunk/docs/topics/http/urls.txt
django/trunk/docs/topics/i18n/formatting.txt
django/trunk/docs/topics/i18n/translation.txt
Log:
Documentation (and some small source code) edits from [17432] - [17537]
Modified: django/trunk/django/core/management/validation.py
===================================================================
--- django/trunk/django/core/management/validation.py 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/django/core/management/validation.py 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -283,9 +283,8 @@
# this format would be nice, but it's a little fiddly).
if '__' in field_name:
continue
- # Skip ordering on pk, this is always a valid order_by field
- # but is an alias and therefore won't be found by
- # opts.get_field.
+ # Skip ordering on pk. This is always a valid order_by field
+ # but is an alias and therefore won't be found by
opts.get_field.
if field_name == 'pk':
continue
try:
Modified: django/trunk/django/middleware/csrf.py
===================================================================
--- django/trunk/django/middleware/csrf.py 2012-02-17 20:03:40 UTC (rev
17539)
+++ django/trunk/django/middleware/csrf.py 2012-02-17 20:04:11 UTC (rev
17540)
@@ -110,23 +110,23 @@
# Mechanism to turn off CSRF checks for test suite.
# It comes after the creation of CSRF cookies, so that
# everything else continues to work exactly the same
- # (e.g. cookies are sent etc), but before the any
- # branches that call reject()
+ # (e.g. cookies are sent, etc.), but before any
+ # branches that call reject().
return self._accept(request)
if request.is_secure():
# Suppose user visits http://example.com/
- # An active network attacker,(man-in-the-middle, MITM) sends a
- # POST form which targets https://example.com/detonate-bomb/
and
- # submits it via javascript.
+ # An active network attacker (man-in-the-middle, MITM) sends a
+ # POST form that targets https://example.com/detonate-bomb/ and
+ # submits it via JavaScript.
#
# The attacker will need to provide a CSRF cookie and token,
but
- # that is no problem for a MITM and the session independent
- # nonce we are using. So the MITM can circumvent the CSRF
+ # that's no problem for a MITM and the session-independent
+ # nonce we're using. So the MITM can circumvent the CSRF
# protection. This is true for any HTTP connection, but anyone
- # using HTTPS expects better! For this reason, for
+ # using HTTPS expects better! For this reason, for
# https://example.com/ we need additional protection that
treats
- # http://example.com/ as completely untrusted. Under HTTPS,
+ # http://example.com/ as completely untrusted. Under HTTPS,
# Barth et al. found that the Referer header is missing for
# same-domain requests in only about 0.2% of cases or less, so
# we can use strict Referer checking.
@@ -141,7 +141,7 @@
)
return self._reject(request, REASON_NO_REFERER)
- # Note that request.get_host() includes the port
+ # Note that request.get_host() includes the port.
good_referer = 'https://%s/' % request.get_host()
if not same_origin(referer, good_referer):
reason = REASON_BAD_REFERER % (referer, good_referer)
@@ -166,14 +166,14 @@
)
return self._reject(request, REASON_NO_CSRF_COOKIE)
- # check non-cookie token for match
+ # Check non-cookie token for match.
request_csrf_token = ""
if request.method == "POST":
request_csrf_token = request.POST.get('csrfmiddlewaretoken',
'')
if request_csrf_token == "":
# Fall back to X-CSRFToken, to make things easier for AJAX,
- # and possible for PUT/DELETE
+ # and possible for PUT/DELETE.
request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '')
if not constant_time_compare(request_csrf_token, csrf_token):
Modified: django/trunk/docs/howto/custom-management-commands.txt
===================================================================
--- django/trunk/docs/howto/custom-management-commands.txt 2012-02-17
20:03:40 UTC (rev 17539)
+++ django/trunk/docs/howto/custom-management-commands.txt 2012-02-17
20:04:11 UTC (rev 17540)
@@ -9,9 +9,8 @@
:doc:`tutorial</intro/tutorial01>`.
To do this, just add a ``management/commands`` directory to the application.
-Each Python module in that directory will be auto-discovered. Modules having
-names not starting with an underscore will be registered as commands that can
be
-executed as an action when you run ``manage.py``::
+Django will register a ``manage.py`` command for each Python module in that
+directory whose name doesn't begin with an underscore. For example::
polls/
__init__.py
Modified: django/trunk/docs/ref/contrib/admin/index.txt
===================================================================
--- django/trunk/docs/ref/contrib/admin/index.txt 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/docs/ref/contrib/admin/index.txt 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -697,8 +697,8 @@
.. note::
- The ``FieldListFilter`` API is currently considered internal and prone
- to refactoring.
+ The ``FieldListFilter`` API is considered internal and might be
+ changed.
.. versionadded:: 1.4
Modified: django/trunk/docs/ref/contrib/gis/install.txt
===================================================================
--- django/trunk/docs/ref/contrib/gis/install.txt 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/docs/ref/contrib/gis/install.txt 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -44,7 +44,7 @@
.. _spatial_database:
-Spatial Database
+Spatial database
----------------
PostgreSQL (with PostGIS), MySQL, Oracle, and SQLite (with SpatiaLite) are
the spatial databases currently supported.
@@ -69,7 +69,7 @@
.. _geospatial_libs:
-Geospatial Libraries
+Geospatial libraries
--------------------
GeoDjango uses and/or provides interfaces for the following open source
geospatial libraries:
@@ -104,7 +104,7 @@
.. _build_from_source:
-Building from Source
+Building from source
====================
When installing from source on UNIX and GNU/Linux systems, please follow
@@ -156,7 +156,7 @@
Troubleshooting
^^^^^^^^^^^^^^^
-Can't find GEOS Library
+Can't find GEOS library
~~~~~~~~~~~~~~~~~~~~~~~
When GeoDjango can't find GEOS, this error is raised:
@@ -297,7 +297,7 @@
Troubleshooting
^^^^^^^^^^^^^^^
-Can't find GDAL Library
+Can't find GDAL library
~~~~~~~~~~~~~~~~~~~~~~~
When GeoDjango can't find the GDAL library, the ``HAS_GDAL`` flag
@@ -410,7 +410,7 @@
.. _spatialitebuild :
-SpatiaLite Library (``libspatialite``) and Tools (``spatialite``)
+SpatiaLite library (``libspatialite``) and tools (``spatialite``)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After SQLite has been built with the R*Tree module enabled, get the latest
@@ -495,12 +495,12 @@
$ sudo python setup.py install
-Post-Installation
+Post-installation
=================
.. _spatialdb_template:
-Creating a Spatial Database Template for PostGIS
+Creating a spatial database template for PostGIS
------------------------------------------------
Creating a spatial database with PostGIS is different than normal because
@@ -549,7 +549,7 @@
the following scripts are available:
=============== =============================================
-PostGIS Version Bash Shell Script
+PostGIS version Bash shell script
=============== =============================================
1.3 :download:`create_template_postgis-1.3.sh`
1.4 :download:`create_template_postgis-1.4.sh`
@@ -572,45 +572,35 @@
.. _create_spatialite_db:
-Creating a Spatial Database for SpatiaLite
--------------------------------------------
+Creating a spatial database for SpatiaLite
+------------------------------------------
-After the SpatiaLite library and tools have been installed, it is now possible
-to create a spatial database for use with GeoDjango.
+After you've installed SpatiaLite, you'll need to create a number of spatial
+metadata tables in your database in order to perform spatial queries.
-For this, a number of spatial metadata tables must be created in the database
-before any spatial query is performed against it.
+If you're using SpatiaLite 3.0 or newer, use the ``spatialite`` utility to
+call the ``InitSpatiaMetaData()`` function, like this::
-If you are using SpatiaLite 3.0 or newer then use the ``spatialite`` utility to
-call the ``InitSpatiaMetaData()`` function which will take care of that (you
can
-safely ignore the error messages shown) then you can skip the rest of this
-section::
-
$ spatialite geodjango.db "SELECT InitSpatialMetaData();"
the SPATIAL_REF_SYS table already contains some row(s)
InitSpatiaMetaData ()error:"table spatial_ref_sys already exists"
0
-If you re using a version of Spatialite older than 3.0 then to achieve the same
-result you need to download a database initialization file and execute the SQL
-queries it contains against your database.
+You can safely ignore the error messages shown. When you've done this, you can
+skip the rest of this section.
-First, get it from the appropiate SpatiaLite Resources page (i.e.
+If you're using a version of SpatiaLite older than 3.0, you'll need to download
+a database-initialization file and execute its SQL queries in your database.
+
+First, get it from the appropriate SpatiaLite Resources page (
http://www.gaia-gis.it/spatialite-2.3.1/resources.html for 2.3 or
http://www.gaia-gis.it/spatialite-2.4.0/ for 2.4)::
$ wget http://www.gaia-gis.it/spatialite-2.3.1/init_spatialite-2.3.sql.gz
$ gunzip init_spatialite-2.3.sql.gz
-(Or, if you are using SpatiaLite 2.4 then do::
+Then, use the ``spatialite`` command to initialize a spatial database::
- $ wget http://www.gaia-gis.it/spatialite-2.4.0/init_spatialite-2.4.sql.gz
- $ gunzip init_spatialite-2.4.sql.gz
-
-)
-
-Now, the ``spatialite`` command can be used to initialize a spatial database::
-
$ spatialite geodjango.db < init_spatialite-2.X.sql
.. note::
@@ -629,15 +619,15 @@
.. _addgoogleprojection:
-Add Google Projection to ``spatial_ref_sys`` table
+Add Google projection to ``spatial_ref_sys`` table
--------------------------------------------------
.. versionchanged:: 1.2
.. note::
- If running PostGIS 1.4 and above, the entry is already included in the
- default ``spatial_ref_sys`` table. You can skip this step.
+ If you're running PostGIS 1.4 or above, you can skip this step. The entry
+ is already included in the default ``spatial_ref_sys`` table.
In order to conduct database transformations to the so-called "Google"
projection (a spherical mercator projection used by Google Maps),
@@ -678,7 +668,7 @@
.. _libsettings:
-Library Environment Settings
+Library environment settings
----------------------------
By far, the most common problem when installing GeoDjango is that the
@@ -701,7 +691,7 @@
export LD_LIBRARY_PATH=/usr/local/lib
-Setting System Library Path
+Setting system library path
^^^^^^^^^^^^^^^^^^^^^^^^^^^
On GNU/Linux systems, there is typically a file in ``/etc/ld.so.conf``, which
may include
@@ -740,7 +730,7 @@
$ sudo yum install binutils
-Platform Specific Instructions
+Platform-specific instructions
==============================
.. _macosx:
@@ -749,7 +739,7 @@
--------
Because of the variety of packaging systems available for OS X, users have
-several different options for installing GeoDjango. These options are:
+several different options for installing GeoDjango. These options are:
* :ref:`kyngchaos`
* :ref:`fink`
@@ -789,7 +779,7 @@
.. _kyngchaos:
-KyngChaos Packages
+KyngChaos packages
^^^^^^^^^^^^^^^^^^
William Kyngesburye provides a number of `geospatial library binary packages`__
@@ -952,9 +942,9 @@
.. note::
The PostGIS SQL files are not placed in the PostgreSQL share directory in
- the Debian and Ubuntu packages, and are located instead in a special
- directory depending on the release. Thus, when :ref:`spatialdb_template`
- use the :download:`create_template_postgis-debian.sh` script instead.
+ the Debian and Ubuntu packages. Instead, they're located in a special
+ directory depending on the release. In this case, use the
+ :download:`create_template_postgis-debian.sh` script
.. _ubuntu:
@@ -1049,10 +1039,11 @@
4.0 (Etch)
^^^^^^^^^^
+
The situation here is the same as that of Ubuntu :ref:`heron` -- in other
words,
some packages must be built from source to work properly with GeoDjango.
-Binary Packages
+Binary packages
~~~~~~~~~~~~~~~
The following command will install acceptable binary packages, as well as
the development tools necessary to build the rest of the requirements::
@@ -1075,7 +1066,7 @@
* ``libgeoip``: for :ref:`GeoIP <ref-geoip>` support
-Source Packages
+Source packages
~~~~~~~~~~~~~~~
You will still have to install :ref:`geosbuild`, :ref:`proj4`,
:ref:`postgis`, and :ref:`gdalbuild` from source. Please follow the
@@ -1104,7 +1095,7 @@
.. _post_install:
-Post-installation Notes
+Post-installation notes
~~~~~~~~~~~~~~~~~~~~~~~
If the PostgreSQL database cluster was not initiated after installing, then it
@@ -1234,7 +1225,7 @@
.. _OSGeo4W installer: http://trac.osgeo.org/osgeo4w/
-Modify Windows Environment
+Modify Windows environment
^^^^^^^^^^^^^^^^^^^^^^^^^^
In order to use GeoDjango, you will need to add your Python and OSGeo4W
@@ -1269,8 +1260,8 @@
then you will need to modify the ``OSGEO4W_ROOT`` and/or ``PYTHON_ROOT``
variables accordingly.
-Install Django and Setup Database
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Install Django and set up database
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finally, :ref:`install Django <installing-official-release>` on your system.
You do not need to create a spatial database template, as one named
Modified: django/trunk/docs/ref/contrib/gis/testing.txt
===================================================================
--- django/trunk/docs/ref/contrib/gis/testing.txt 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/docs/ref/contrib/gis/testing.txt 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -1,11 +1,11 @@
======================
-Testing GeoDjango Apps
+Testing GeoDjango apps
======================
.. versionchanged:: 1.2
In Django 1.2, the addition of :ref:`spatial-backends` simplified the
-process of testing GeoDjango applications -- the process is now the
+process of testing GeoDjango applications. The process is now the
same as :doc:`/topics/testing`.
Included in this documentation are some additional notes and settings
@@ -31,7 +31,7 @@
.. versionchanged:: 1.2
This setting may be used to customize the name of the PostGIS template
-database to use. In Django versions 1.2 and above, it automatically
+database to use. In Django versions 1.2 and above, it automatically
defaults to ``'template_postgis'`` (the same name used in the
:ref:`installation documentation <spatialdb_template>`).
@@ -42,25 +42,25 @@
When GeoDjango's spatial backend initializes on PostGIS, it has to perform
a SQL query to determine the version in order to figure out what
-features are available. Advanced users wishing to prevent this additional
+features are available. Advanced users wishing to prevent this additional
query may set the version manually using a 3-tuple of integers specifying
-the major, minor, and subminor version numbers for PostGIS. For example,
+the major, minor, and subminor version numbers for PostGIS. For example,
to configure for PostGIS 1.5.2 you would use::
POSTGIS_VERSION = (1, 5, 2)
-Obtaining Sufficient Privileges
+Obtaining sufficient privileges
-------------------------------
Depending on your configuration, this section describes several methods to
configure a database user with sufficient privileges to run tests for
-GeoDjango applications on PostgreSQL. If your
+GeoDjango applications on PostgreSQL. If your
:ref:`spatial database template <spatialdb_template>`
was created like in the instructions, then your testing database user
-only needs to have the ability to create databases. In other configurations,
+only needs to have the ability to create databases. In other configurations,
you may be required to use a database superuser.
-Create Database User
+Create database user
^^^^^^^^^^^^^^^^^^^^
To make database user with the ability to create databases, use the
@@ -76,7 +76,7 @@
postgres# ALTER ROLE <user_name> CREATEDB NOSUPERUSER NOCREATEROLE;
-Create Database Superuser
+Create database superuser
^^^^^^^^^^^^^^^^^^^^^^^^^
This may be done at the time the user is created, for example::
@@ -89,7 +89,7 @@
postgres# ALTER ROLE <user_name> SUPERUSER;
-Create Local PostgreSQL Database
+Create local PostgreSQL database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Initialize database: ``initdb -D /path/to/user/db``
@@ -114,8 +114,8 @@
SpatiaLite
==========
-You need to make sure needed spatial tables are created in your test spatial
-database as described in :ref:`create_spatialite_db`. Then all you have to do
is::
+Make sure the necessary spatial tables are created in your test spatial
+database, as described in :ref:`create_spatialite_db`. Then just do this::
$ python manage.py test
@@ -127,18 +127,18 @@
``SPATIALITE_SQL``
^^^^^^^^^^^^^^^^^^
-(only relevant when using a SpatiaLite version older than 3.0).
+Only relevant when using a SpatiaLite version older than 3.0.
By default, the GeoDjango test runner looks for the SpatiaLite SQL in the
same directory where it was invoked (by default the same directory where
-``manage.py`` is located). If you want to use a different location, then
-you may add the following to your settings::
+``manage.py`` is located). To use a different location, add the following to
+your settings::
SPATIALITE_SQL='/path/to/init_spatialite-2.3.sql'
.. _geodjango-tests:
-GeoDjango Tests
+GeoDjango tests
===============
.. versionchanged:: 1.3
Modified: django/trunk/docs/ref/django-admin.txt
===================================================================
--- django/trunk/docs/ref/django-admin.txt 2012-02-17 20:03:40 UTC (rev
17539)
+++ django/trunk/docs/ref/django-admin.txt 2012-02-17 20:04:11 UTC (rev
17540)
@@ -954,10 +954,10 @@
.. versionadded:: 1.4
-When Django copies the app template files, it also renders the files
-whose extension matches those passed with the ``--extension`` option (``py``
-by default) and those files which names are passed with the ``--name`` option
-using the template engine. The :class:`template context
+When Django copies the app template files, it also renders certain files
+through the template engine: the files whose extensions match the
+``--extension`` option (``py`` by default) and the files whose names are passed
+with the ``--name`` option. The :class:`template context
<django.template.Context>` used is:
- Any option passed to the startapp command
@@ -1017,10 +1017,10 @@
django-admin.py startproject
--template=/Users/jezdez/Code/my_project_template myproject
-When Django copies the project template files, it will also render the files
-whose extension matches those passed with the ``--extension`` option (``py``
-by default) and those files which names are passed with the ``--name`` option
-using the template engine. The :class:`template context
+When Django copies the project template files, it also renders certain files
+through the template engine: the files whose extensions match the
+``--extension`` option (``py`` by default) and the files whose names are passed
+with the ``--name`` option. The :class:`template context
<django.template.Context>` used is:
- Any option passed to the startproject command
Modified: django/trunk/docs/ref/settings.txt
===================================================================
--- django/trunk/docs/ref/settings.txt 2012-02-17 20:03:40 UTC (rev 17539)
+++ django/trunk/docs/ref/settings.txt 2012-02-17 20:04:11 UTC (rev 17540)
@@ -756,32 +756,45 @@
A boolean that turns on/off debug mode.
-If you define custom settings, `django/views/debug.py`_ has a
-``HIDDEN_SETTINGS`` regular expression which will hide from the DEBUG view
-anything that contains ``'API'``, ``'TOKEN'``, ``'KEY'``, ``'SECRET'``,
-``'PASS'``, ``'PROFANITIES_LIST'``, or ``'SIGNATURE'``. This allows untrusted
-users to be able to give backtraces without seeing sensitive (or offensive)
-settings.
+Never deploy a site into production with :setting:`DEBUG` turned on.
+Did you catch that? NEVER deploy a site into production with :setting:`DEBUG`
+turned on.
+
+One of the main features of debug mode is the display of detailed error pages.
+If your app raises an exception when ``DEBUG`` is ``True``, Django will display
+a detailed traceback, including a lot of metadata about your environment, such
+as all the currently defined Django settings (from ``settings.py``).
+
+As a security measure, Django will *not* include settings that might be
+sensitive (or offensive), such as ``SECRET_KEY`` or ``PROFANITIES_LIST``.
+Specifically, it will exclude any setting whose name includes any of the
+following:
+
+ * API
+ * KEY
+ * PASS
+ * PROFANITIES_LIST
+ * SECRET
+ * SIGNATURE
+ * TOKEN
+
.. versionchanged:: 1.4
- ``'PASSWORD'`` changed to ``'PASS'``. ``'API'``, ``'TOKEN'``, ``'KEY'``
+ We changed ``'PASSWORD'`` ``'PASS'``. ``'API'``, ``'TOKEN'`` and ``'KEY'``
were added.
-Note that due to how regular expression matching works ``'PASS'`` will also
-match PASSWORD, just as ``'TOKEN'`` will also match TOKENIZED and so on.
+Note that these are *partial* matches. ``'PASS'`` will also match PASSWORD,
+just as ``'TOKEN'`` will also match TOKENIZED and so on.
Still, note that there are always going to be sections of your debug output
that are inappropriate for public consumption. File paths, configuration
-options, and the like all give attackers extra information about your server.
+options and the like all give attackers extra information about your server.
It is also important to remember that when running with :setting:`DEBUG`
turned on, Django will remember every SQL query it executes. This is useful
-when you are debugging, but on a production server, it will rapidly consume
-memory.
+when you're debugging, but it'll rapidly consume memory on a production server.
-Never deploy a site into production with :setting:`DEBUG` turned on.
-
.. _django/views/debug.py:
http://code.djangoproject.com/browser/django/trunk/django/views/debug.py
DEBUG_PROPAGATE_EXCEPTIONS
Modified: django/trunk/docs/releases/1.4.txt
===================================================================
--- django/trunk/docs/releases/1.4.txt 2012-02-17 20:03:40 UTC (rev 17539)
+++ django/trunk/docs/releases/1.4.txt 2012-02-17 20:04:11 UTC (rev 17540)
@@ -171,14 +171,13 @@
:doc:`cryptographic signing </topics/signing>` to store the session data in
the client's browser.
-+.. warning::
-+
-+ Session data is signed and validated by the server, but is not
-+ encrypted. This means that a user can view any data stored in the
-+ session, but cannot change it. Please read the documentation for
-+ further clarification before using this backend.
-+
+.. warning::
+ Session data is signed and validated by the server, but it's not
+ encrypted. This means a user can view any data stored in the
+ session but cannot change it. Please read the documentation for
+ further clarification before using this backend.
+
See the :ref:`cookie-based session backend <cookie-session-backend>` docs for
more information.
@@ -1027,9 +1026,10 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:djadmin:`manage.py help <help>` now groups available commands by application.
-If you depended on its output, for instance if you parsed it, you must update
-your scripts. To obtain the list of all available management commands in a
-script, you can use :djadmin:`manage.py help --commands <help>` instead.
+If you depended on the output of this command -- if you parsed it, for example
+-- then you'll need to update your code. To get a list of all available
+management commands in a script, use
+:djadmin:`manage.py help --commands <help>` instead.
Features deprecated in 1.4
==========================
@@ -1185,17 +1185,14 @@
actually provided the body of the HTTP request. It's been renamed to
``HttpRequest.body``, and ``HttpRequest.raw_post_data`` has been deprecated.
-``django.contrib.sitemaps`` bugfix with potential performance implications
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+``django.contrib.sitemaps`` bug fix with potential performance implications
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In previous versions the Paginator objects used in sitemap classes were
-cached and could result in stale sitemap indexes. Removing this cache causes
-new Paginator objects to be created and the
+In previous versions, ``Paginator`` objects used in sitemap classes were
+cached, which could result in stale site maps. We've removed the caching, so
+each request to a site map now creates a new Paginator object and calls the
:attr:`~django.contrib.sitemaps.Sitemap.items()` method of the
-:class:`~django.contrib.sitemaps.Sitemap` subclass to be called during every
-sitemap-related request.
-
-If the :attr:`django.contrib.sitemaps.Sitemap.items()` method returns a
-``QuerySet`` its length will be evaluated which may lead to extra database
-queries. To mitigate the performance impact consider using the :doc:`caching
-framework </topics/cache>`.
+:class:`~django.contrib.sitemaps.Sitemap` subclass. Depending on what your
+``items()`` method is doing, this may have a negative performance impact.
+To mitigate the performance impact, consider using the :doc:`caching
+framework </topics/cache>` within your ``Sitemap`` subclass.
Modified: django/trunk/docs/topics/http/urls.txt
===================================================================
--- django/trunk/docs/topics/http/urls.txt 2012-02-17 20:03:40 UTC (rev
17539)
+++ django/trunk/docs/topics/http/urls.txt 2012-02-17 20:04:11 UTC (rev
17540)
@@ -440,7 +440,7 @@
At any point, your ``urlpatterns`` can "include" other URLconf modules. This
essentially "roots" a set of URLs below other ones.
-For example, here's an except of the URLconf for the `Django Web site`_
+For example, here's an excerpt of the URLconf for the `Django Web site`_
itself. It includes a number of other URLconfs::
from django.conf.urls import patterns, url, include
@@ -849,7 +849,7 @@
namespaces into URLs on specific application instances, according to the
:ref:`namespaced URL resolution strategy
<topics-http-reversing-url-namespaces>`.
-You can use ``kwargs`` instead of ``args``, for example::
+You can use ``kwargs`` instead of ``args``. For example::
>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
'/admin/auth/'
@@ -976,7 +976,7 @@
information it provides) is not available in earlier Django releases.
One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
-if a view would raise a ``Http404`` error before redirecting to it::
+whether a view would raise a ``Http404`` error before redirecting to it::
from urlparse import urlparse
from django.core.urlresolvers import resolve
Modified: django/trunk/docs/topics/i18n/formatting.txt
===================================================================
--- django/trunk/docs/topics/i18n/formatting.txt 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/docs/topics/i18n/formatting.txt 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -186,16 +186,15 @@
Limitations of the provided locale formats
==========================================
-Some locales use context-sensitive formats for numbers, which Djangos
+Some locales use context-sensitive formats for numbers, which Django's
localization system cannot handle automatically.
-
Switzerland (German)
--------------------
The Swiss number formatting depends on the type of number that is being
formatted. For monetary values, a comma is used as the thousand separator and
-a decimal point for the decimal separator, for all other numbers, a comma is
+a decimal point for the decimal separator. For all other numbers, a comma is
used as decimal separator and a space as thousand separator. The locale format
provided by Django uses the generic separators, a comma for decimal and a space
for thousand separators.
Modified: django/trunk/docs/topics/i18n/translation.txt
===================================================================
--- django/trunk/docs/topics/i18n/translation.txt 2012-02-17 20:03:40 UTC
(rev 17539)
+++ django/trunk/docs/topics/i18n/translation.txt 2012-02-17 20:04:11 UTC
(rev 17540)
@@ -297,7 +297,7 @@
Use the lazy versions of translation functions in
:mod:`django.utils.translation` (easily recognizable by the ``lazy`` suffix in
their names) to translate strings lazily -- when the value is accessed rather
-than when they are called.
+than when they're called.
These functions store a lazy reference to the string -- not the actual
translation. The translation itself will be done when the string is used in a
@@ -306,10 +306,10 @@
This is essential when calls to these functions are located in code paths that
are executed at module load time.
-As this is something that can easily happen when defining models, forms and
-model forms (the declarative notation Django offers for them is implemented in
a
-way such that their fields are actually class level attributes) this means you
-need to make sure to use lazy translations in the following cases:
+This is something that can easily happen when defining models, forms and
+model forms, because Django implements these such that their fields are
+actually class-level attributes. For that reason, make sure to use lazy
+translations in the following cases:
Model fields and relationships ``verbose_name`` and ``help_text`` option values
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
