Ensured :doc: role uses absolute targets in docs.

This commit is contained in:
Adam Johnson 2025-06-27 14:33:40 +01:00 committed by nessita
parent ae03f81ffa
commit 56955636e6
24 changed files with 247 additions and 237 deletions

View file

@ -75,7 +75,7 @@ models defined in your installed apps.
Usage
=====
:doc:`Using Django's default implementation <default>`
:doc:`Using Django's default implementation </topics/auth/default>`
* :ref:`Working with User objects <user-objects>`
* :ref:`Permissions and authorization <topic-authorization>`
@ -84,6 +84,6 @@ Usage
:doc:`API reference for the default implementation </ref/contrib/auth>`
:doc:`Customizing Users and authentication <customizing>`
:doc:`Customizing Users and authentication </topics/auth/customizing>`
:doc:`Password management in Django <passwords>`
:doc:`Password management in Django </topics/auth/passwords>`

View file

@ -5,8 +5,8 @@ Using mixins with class-based views
.. caution::
This is an advanced topic. A working knowledge of :doc:`Django's
class-based views<index>` is advised before exploring these
techniques.
class-based views </topics/class-based-views/index>` is advised before
exploring these techniques.
Django's built-in class-based views provide a lot of functionality,
but some of it you may want to use separately. For instance, you may
@ -120,9 +120,9 @@ but the main one that most people are going to use is
``<app_label>/<model_name>_detail.html``. The ``_detail`` part can be changed
by setting
:attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
on a subclass to something else. (For instance, the :doc:`generic edit
views<generic-editing>` use ``_form`` for create and update views, and
``_confirm_delete`` for delete views.)
on a subclass to something else. (For instance, the :doc:`generic edit views
</topics/class-based-views/generic-editing>` use ``_form`` for create and
update views, and ``_confirm_delete`` for delete views.)
``ListView``: working with many Django objects
----------------------------------------------
@ -213,8 +213,8 @@ in the subclass. However if we want our processing to work on a particular
object, identified from the URL, we'll want the functionality provided by
:class:`~django.views.generic.detail.SingleObjectMixin`.
We'll demonstrate this with the ``Author`` model we used in the
:doc:`generic class-based views introduction<generic-display>`.
We'll demonstrate this with the ``Author`` model we used in the :doc:`generic
class-based views introduction </topics/class-based-views/generic-display>`.
.. code-block:: python
:caption: ``views.py``
@ -390,11 +390,11 @@ increasingly complex as you try to do so, and a good rule of thumb is:
.. hint::
Each of your views should use only mixins or views from one of the
groups of generic class-based views: :doc:`detail,
list<generic-display>`, :doc:`editing<generic-editing>` and
date. For example it's fine to combine
:class:`TemplateView` (built in view) with
Each of your views should use only mixins or views from one of the groups
of generic class-based views: :doc:`detail, list
</topics/class-based-views/generic-display>`, :doc:`editing
</topics/class-based-views/generic-editing>` and date. For example it's
fine to combine :class:`TemplateView` (built in view) with
:class:`~django.views.generic.list.MultipleObjectMixin` (generic list), but
you're likely to have problems combining ``SingleObjectMixin`` (generic
detail) with ``MultipleObjectMixin`` (generic list).

View file

@ -22,11 +22,11 @@ it should be doing.
The preferred way to write tests in Django is using the :mod:`unittest` module
built-in to the Python standard library. This is covered in detail in the
:doc:`overview` document.
:doc:`/topics/testing/overview` document.
You can also use any *other* Python test framework; Django provides an API and
tools for that kind of integration. They are described in the
:ref:`other-testing-frameworks` section of :doc:`advanced`.
:ref:`other-testing-frameworks` section of :doc:`/topics/testing/advanced`.
.. toctree::
:maxdepth: 1