summaryrefslogtreecommitdiff
path: root/docs/topics/class-based-views/mixins.txt
diff options
context:
space:
mode:
authorDavid Smith <smithdc@gmail.com>2025-07-25 10:24:17 +0100
committernessita <124304+nessita@users.noreply.github.com>2025-08-25 10:51:10 -0300
commitf81e6e3a53ee36e3f730a71aa55a5744982dd016 (patch)
tree44a4fdd64e2d1489d80b1af8bd1ac3c7af3ad0dd /docs/topics/class-based-views/mixins.txt
parent4286a23df64f6ce3b9b6ed097f4d1aac7d9e0de4 (diff)
Refs #36485 -- Rewrapped docs to 79 columns line length.
Lines in the docs files were manually adjusted to conform to the 79 columns limit per line (plus newline), improving readability and consistency across the content.
Diffstat (limited to 'docs/topics/class-based-views/mixins.txt')
-rw-r--r--docs/topics/class-based-views/mixins.txt49
1 files changed, 23 insertions, 26 deletions
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index bb1a6349dc..6b2c435e1b 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -112,11 +112,10 @@ context data for template renders.
To then make a :class:`~django.template.response.TemplateResponse`,
:class:`DetailView` uses
-:class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`,
-which extends :class:`~django.views.generic.base.TemplateResponseMixin`,
-overriding
-:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names`
-as discussed above. It actually provides a fairly sophisticated set of options,
+:class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`, which
+extends :class:`~django.views.generic.base.TemplateResponseMixin`, overriding
+:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names` as
+discussed above. It actually provides a fairly sophisticated set of options,
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
@@ -135,20 +134,18 @@ paginated) list of objects, typically a
using that list of objects.
To get the objects, :class:`~django.views.generic.list.ListView` uses
-:class:`~django.views.generic.list.MultipleObjectMixin`, which
-provides both
-:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset`
-and
-:meth:`~django.views.generic.list.MultipleObjectMixin.paginate_queryset`. Unlike
-with :class:`~django.views.generic.detail.SingleObjectMixin`, there's no need
-to key off parts of the URL to figure out the queryset to work with, so the
-default uses the
+:class:`~django.views.generic.list.MultipleObjectMixin`, which provides both
+:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` and
+:meth:`~django.views.generic.list.MultipleObjectMixin.paginate_queryset`.
+Unlike with :class:`~django.views.generic.detail.SingleObjectMixin`, there's no
+need to key off parts of the URL to figure out the queryset to work with, so
+the default uses the
:attr:`~django.views.generic.list.MultipleObjectMixin.queryset` or
-:attr:`~django.views.generic.list.MultipleObjectMixin.model` attribute
-on the view class. A common reason to override
-:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset`
-here would be to dynamically vary the objects, such as depending on
-the current user or to exclude posts in the future for a blog.
+:attr:`~django.views.generic.list.MultipleObjectMixin.model` attribute on the
+view class. A common reason to override
+:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` here would
+be to dynamically vary the objects, such as depending on the current user or to
+exclude posts in the future for a blog.
:class:`~django.views.generic.list.MultipleObjectMixin` also overrides
:meth:`~django.views.generic.base.ContextMixin.get_context_data` to
@@ -159,13 +156,12 @@ it.
To make a :class:`~django.template.response.TemplateResponse`,
:class:`ListView` then uses
-:class:`~django.views.generic.list.MultipleObjectTemplateResponseMixin`;
-as with :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`
+:class:`~django.views.generic.list.MultipleObjectTemplateResponseMixin`; as
+with :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`
above, this overrides ``get_template_names()`` to provide :meth:`a range of
-options <django.views.generic.list.MultipleObjectTemplateResponseMixin>`,
-with the most commonly-used being
-``<app_label>/<model_name>_list.html``, with the ``_list`` part again
-being taken from the
+options <django.views.generic.list.MultipleObjectTemplateResponseMixin>`, with
+the most commonly-used being ``<app_label>/<model_name>_list.html``, with the
+``_list`` part again being taken from the
:attr:`~django.views.generic.list.MultipleObjectTemplateResponseMixin.template_name_suffix`
attribute. (The date based generic views use suffixes such as ``_archive``,
``_archive_year`` and so on to use different templates for the various
@@ -635,8 +631,9 @@ For example, a JSON mixin might look something like this::
information on how to correctly transform Django models and querysets into
JSON.
-This mixin provides a ``render_to_json_response()`` method with the same signature
-as :func:`~django.views.generic.base.TemplateResponseMixin.render_to_response`.
+This mixin provides a ``render_to_json_response()`` method with the same
+signature as
+:func:`~django.views.generic.base.TemplateResponseMixin.render_to_response`.
To use it, we need to mix it into a ``TemplateView`` for example, and override
``render_to_response()`` to call ``render_to_json_response()`` instead::