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.

docs/topics/class-based-views/generic-display.txt

@@ -4,8 +4,8 @@ Built-in class-based generic views
 
 Writing web applications can be monotonous, because we repeat certain patterns
 again and again. Django tries to take away some of that monotony at the model
-and template layers, but web developers also experience this boredom at the view
-level.
+and template layers, but web developers also experience this boredom at the
+view level.
 
 Django's *generic views* were developed to ease that pain. They take certain
 common idioms and patterns found in view development and abstract them so that
@@ -229,8 +229,8 @@ you can override it to send more::
     Generally, ``get_context_data`` will merge the context data of all parent
     classes with those of the current class. To preserve this behavior in your
     own classes where you want to alter the context, you should be sure to call
-    ``get_context_data`` on the super class. When no two classes try to define the
-    same key, this will give the expected results. However if any class
+    ``get_context_data`` on the super class. When no two classes try to define
+    the same key, this will give the expected results. However if any class
     attempts to override a key after parent classes have set it (after the call
     to super), any children of that class will also need to explicitly set it
     after super if they want to be sure to override all parents. If you're
@@ -295,8 +295,8 @@ list of books by a particular publisher, you can use the same technique::
         template_name = "books/acme_list.html"
 
 Notice that along with a filtered ``queryset``, we're also using a custom
-template name. If we didn't, the generic view would use the same template as the
-"vanilla" object list, which might not be what we want.
+template name. If we didn't, the generic view would use the same template as
+the "vanilla" object list, which might not be what we want.
 
 Also notice that this isn't a very elegant way of doing publisher-specific
 books. If we want to add another publisher page, we'd need another handful of
@@ -317,8 +317,8 @@ Dynamic filtering
 
 Another common need is to filter down the objects given in a list page by some
 key in the URL. Earlier we hardcoded the publisher's name in the URLconf, but
-what if we wanted to write a view that displayed all the books by some arbitrary
-publisher?
+what if we wanted to write a view that displayed all the books by some
+arbitrary publisher?
 
 Handily, the ``ListView`` has a
 :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` method we

docs/topics/class-based-views/generic-editing.txt

@@ -84,7 +84,8 @@ special requirements; see below for examples.
 You don't even need to provide a ``success_url`` for
 :class:`~django.views.generic.edit.CreateView` or
 :class:`~django.views.generic.edit.UpdateView` - they will use
-:meth:`~django.db.models.Model.get_absolute_url` on the model object if available.
+:meth:`~django.db.models.Model.get_absolute_url` on the model object if
+available.
 
 If you want to use a custom :class:`~django.forms.ModelForm` (for instance to
 add extra validation), set
@@ -146,8 +147,9 @@ inner ``Meta`` class on :class:`~django.forms.ModelForm`. Unless you define the
 form class in another way, the attribute is required and the view will raise
 an :exc:`~django.core.exceptions.ImproperlyConfigured` exception if it's not.
 
-If you specify both the :attr:`~django.views.generic.edit.ModelFormMixin.fields`
-and :attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an
+If you specify both the
+:attr:`~django.views.generic.edit.ModelFormMixin.fields` and
+:attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an
 :exc:`~django.core.exceptions.ImproperlyConfigured` exception will be raised.
 
 Finally, we hook these new views into the URLconf:

docs/topics/class-based-views/index.txt

@@ -23,8 +23,8 @@ Basic examples
 ==============
 
 Django provides base view classes which will suit a wide range of applications.
-All views inherit from the :class:`~django.views.generic.base.View` class, which
-handles linking the view into the URLs, HTTP method dispatching and other
+All views inherit from the :class:`~django.views.generic.base.View` class,
+which handles linking the view into the URLs, HTTP method dispatching and other
 common features. :class:`~django.views.generic.base.RedirectView` provides a
 HTTP redirect, and :class:`~django.views.generic.base.TemplateView` extends the
 base class to make it also render a template.
@@ -84,7 +84,8 @@ method instead, which provides a function-like entry to class-based views::
 
 
 For more information on how to use the built in generic views, consult the next
-topic on :doc:`generic class-based views</topics/class-based-views/generic-display>`.
+topic on
+:doc:`generic class-based views</topics/class-based-views/generic-display>`.
 
 .. _supporting-other-http-methods:
 

docs/topics/class-based-views/intro.txt

@@ -17,7 +17,8 @@ The relationship and history of generic views, class-based views, and class-base
 
 In the beginning there was only the view function contract, Django passed your
 function an :class:`~django.http.HttpRequest` and expected back an
-:class:`~django.http.HttpResponse`. This was the extent of what Django provided.
+:class:`~django.http.HttpResponse`. This was the extent of what Django
+provided.
 
 Early on it was recognized that there were common idioms and patterns found in
 view development. Function-based generic views were introduced to abstract

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::