diff --git a/docs/ref/exceptions.txt b/docs/ref/exceptions.txt
index 947815b7fe..a42bdafb7f 100644
--- a/docs/ref/exceptions.txt
+++ b/docs/ref/exceptions.txt
@@ -25,7 +25,7 @@ ObjectDoesNotExist and DoesNotExist
exception that is provided on every model class as a way of
identifying the specific type of object that could not be found.
- See :meth:`~django.db.models.QuerySet.get()` for further information
+ See :meth:`~django.db.models.query.QuerySet.get()` for further information
on :exc:`ObjectDoesNotExist` and :exc:`DoesNotExist`.
MultipleObjectsReturned
@@ -38,7 +38,7 @@ MultipleObjectsReturned
class contains a subclassed version that can be used to identify the
specific object type that has returned multiple objects.
- See :meth:`~django.db.models.QuerySet.get()` for further information.
+ See :meth:`~django.db.models.query.QuerySet.get()` for further information.
SuspiciousOperation
-------------------
@@ -133,6 +133,17 @@ Specification v2.0`_ for further information.
.. _`PEP 249 - Python Database API Specification v2.0`: http://www.python.org/dev/peps/pep-0249/
+.. currentmodule:: django.db.transaction
+
+Transaction Exceptions
+======================
+
+.. exception:: TransactionManagementError
+
+ The :exc:`TransactionManagementError` is raised for any and all problems
+ related to database transactions. It is available from
+ :mod:`django.db.transaction`.
+
Python Exceptions
=================
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
index 0a589f0bd4..54114d07a6 100644
--- a/docs/ref/generic-views.txt
+++ b/docs/ref/generic-views.txt
@@ -29,6 +29,8 @@ Most generic views require the ``queryset`` key, which is a ``QuerySet``
instance; see :doc:`/topics/db/queries` for more information about ``QuerySet``
objects.
+.. module:: django.views.generic.simple
+
"Simple" generic views
======================
@@ -146,6 +148,8 @@ string is written as ``"%7Ejacob/"`` (with only a single ``%``), an exception wo
('^bar/$', redirect_to, {'url': '%%7Ejacob.'}),
)
+.. module:: django.views.generic.date_based
+
Date-based generic views
========================
@@ -677,6 +681,8 @@ In addition to ``extra_context``, the template's context will be:
``template_object_name`` is ``'foo'``, this variable's name will be
``foo``.
+.. module:: django.views.generic.list_detail
+
List/detail generic views
=========================
@@ -862,6 +868,8 @@ In addition to ``extra_context``, the template's context will be:
``template_object_name`` is ``'foo'``, this variable's name will be
``foo``.
+.. module:: django.views.generic.create_update
+
Create/update/delete generic views
==================================
diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt
index 944f3b9bb8..b02d0edea0 100644
--- a/docs/releases/1.3.txt
+++ b/docs/releases/1.3.txt
@@ -197,15 +197,15 @@ additional data into the context.
However, you can't (easily) modify the content of a basic
:class:`~django.http.HttpResponse` after it has been constructed. To
overcome this limitation, Django 1.3 adds a new
-:class:`~django.template.TemplateResponse` class. Unlike basic
+:class:`~django.template.response.TemplateResponse` class. Unlike basic
:class:`~django.http.HttpResponse` objects,
-:class:`~django.template.TemplateResponse` objects retain the details
+:class:`~django.template.response.TemplateResponse` objects retain the details
of the template and context that was provided by the view to compute
the response. The final output of the response is not computed until
it is needed, later in the response process.
For more details, see the :doc:`documentation </ref/template-response>`
-on the :class:`~django.template.TemplateResponse` class.
+on the :class:`~django.template.response.TemplateResponse` class.
Caching changes
~~~~~~~~~~~~~~~
@@ -253,11 +253,11 @@ when using :ref:`spatial database backends <spatial-backends>`.
``MEDIA_URL`` and ``STATIC_URL`` must end in a slash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Previously, the ``MEDIA_URL`` setting only required a trailing slash if it
-contained a suffix beyond the domain name.
+Previously, the :setting:`MEDIA_URL` setting only required a trailing slash if
+it contained a suffix beyond the domain name.
-A trailing slash is now *required* for ``MEDIA_URL`` and the new
-``STATIC_URL`` setting as long as it is not blank. This ensures there is
+A trailing slash is now *required* for :setting:`MEDIA_URL` and the new
+:setting:`STATIC_URL` setting as long as it is not blank. This ensures there is
a consistent way to combine paths in templates.
Project settings which provide either of both settings without a trailing
@@ -279,31 +279,34 @@ To compensate for this, the focus of the Django 1.3 development
process has been on adding lots of smaller, long standing feature
requests. These include:
-* Improved tools for accessing and manipulating the current ``Site``
- object in :doc:`the sites framework </ref/contrib/sites>`.
+* Improved tools for accessing and manipulating the current
+ :class:`~django.contrib.sites.models.Site` object in
+ :doc:`the sites framework </ref/contrib/sites>`.
* A :class:`~django.test.client.RequestFactory` for mocking requests
in tests.
* A new test assertion --
- :meth:`~django.test.client.Client.assertNumQueries` -- making it
+ :meth:`~django.test.TestCase.assertNumQueries` -- making it
easier to test the database activity associated with a view.
-* Support for lookups spanning relations in admin's ``list_filter``.
+* Support for lookups spanning relations in admin's
+ :attr:`~django.contrib.admin.ModelAdmin.list_filter`.
-* Support for _HTTPOnly cookies.
+* Support for HTTPOnly_ cookies.
-* :meth:`mail_admins()` and :meth:`mail_managers()` now support
- easily attaching HTML content to messages.
+* :meth:`~django.core.mail.mail_admins()` and
+ :meth:`~django.core.mail.mail_managers()` now support easily attaching
+ HTML content to messages.
-* :class:`EmailMessage` now supports CC's.
+* :class:`~django.core.mail.EmailMessage` now supports CC's.
* Error emails now include more of the detail and formatting of the
debug server error page.
-* :meth:`simple_tag` now accepts a :attr:`takes_context` argument,
- making it easier to write simple template tags that require access
- to template context.
+* :meth:`~django.template.Library.simple_tag` now accepts a
+ ``takes_context`` argument, making it easier to write simple
+ template tags that require access to template context.
* A new :meth:`~django.shortcuts.render()` shortcut -- an alternative
to :meth:`~django.shortcuts.render_to_response()` providing a
@@ -381,10 +384,11 @@ explicitly indicate this. For example::
Clearable default widget for FileField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Django 1.3 now includes a ``ClearableFileInput`` form widget in addition to
-``FileInput``. ``ClearableFileInput`` renders with a checkbox to clear the
-field's value (if the field has a value and is not required); ``FileInput``
-provided no means for clearing an existing file from a ``FileField``.
+Django 1.3 now includes a :class:`~django.forms.ClearableFileInput` form widget
+in addition to :class:`~django.forms.FileInput`. ``ClearableFileInput`` renders
+with a checkbox to clear the field's value (if the field has a value and is not
+required); ``FileInput`` provided no means for clearing an existing file from
+a ``FileField``.
``ClearableFileInput`` is now the default widget for a ``FileField``, so
existing forms including ``FileField`` without assigning a custom widget will
@@ -437,7 +441,7 @@ of a web framework, we have "fixed" the problem by making the list of
prohibited words an empty list.
If you want to restore the old behavior, simply put a
-``PROFANITIES_LIST`` setting in your settings file that includes the
+:setting:`PROFANITIES_LIST` setting in your settings file that includes the
words that you want to prohibit (see the `commit that implemented this
change`_ if you want to see the list of words that was historically
prohibited). However, if avoiding profanities is important to you, you
@@ -622,7 +626,8 @@ transactions that are being managed using
return render_to_response('template', {'object':obj})
Prior to Django 1.3, this would work without error. However, under
-Django 1.3, this will raise a :class:`TransactionManagementError` because
+Django 1.3, this will raise a
+:class:`~django.db.transaction.TransactionManagementError` because
the read operation that retrieves the ``MyObject`` instance leaves the
transaction in a dirty state.
@@ -868,12 +873,12 @@ identical to their old versions; only the module location has changed.
Removal of ``XMLField``
~~~~~~~~~~~~~~~~~~~~~~~
-When Django was first released, Django included an ``XMLField`` that
-performed automatic XML validation for any field input. However, this
-validation function hasn't been performed since the introduction of
-``newforms``, prior to the 1.0 release. As a result, ``XMLField`` as
-currently implemented is functionally indistinguishable from a simple
-``TextField``.
+When Django was first released, Django included an
+:class:`~django.db.models.XMLField` that performed automatic XML validation
+for any field input. However, this validation function hasn't been
+performed since the introduction of ``newforms``, prior to the 1.0 release.
+As a result, ``XMLField`` as currently implemented is functionally
+indistinguishable from a simple :class:`~django.db.models.TextField`.
For this reason, Django 1.3 has fast-tracked the deprecation of
``XMLField`` -- instead of a two-release deprecation, ``XMLField``
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 6e7288ec1d..a5bb7470ad 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -2,7 +2,7 @@
Managing database transactions
==============================
-.. currentmodule:: django.db.transaction
+.. module:: django.db.transaction
Django gives you a few ways to control how database transactions are managed,
if you're using a database that supports transactions.