Использование примесей с представлениями на основе классов

DetailView: работа с одним объектом Django

Чтобы показать подробную информацию об объекте, нужно выполнить два действия: получить объект, а затем сформировать TemplateResponse с подходящим шаблоном и этим объектом в качестве контекста.

Для получения объекта DetailView использует SingleObjectMixin, которая предоставляет метод get_object(). Он определяет объект на основе URL запроса (ищет именованные аргументы pk и slug, объявленные в URLConf, и получает объект либо из атрибута model представления, либо из атрибута queryset, если он задан). SingleObjectMixin также переопределяет get_context_data(), который используется во всех встроенных представлениях Django на основе классов для предоставления данных контекста при отображении шаблонов.

Для формирования TemplateResponse DetailView использует SingleObjectTemplateResponseMixin, которая расширяет TemplateResponseMixin, переопределяя get_template_names(), как описано выше. Она предоставляет довольно широкий набор возможностей, но чаще всего используется <app_label>/<model_name>_detail.html. Часть _detail можно изменить, задав для подкласса атрибут template_name_suffix с другим значением. (Например, универсальные представления редактирования используют _form для представлений создания и обновления, а _confirm_delete — для представлений удаления.)

ListView: работа со множеством объектов Django

Для списков объектов применяется примерно тот же подход: нам нужен список объектов (возможно, разбитый на страницы), обычно это QuerySet, после чего нужно сформировать TemplateResponse с подходящим шаблоном, используя этот список объектов.

Для получения объектов ListView использует MultipleObjectMixin, которая предоставляет методы get_queryset() и paginate_queryset(). В отличие от SingleObjectMixin, здесь не нужно использовать части URL для определения queryset, поэтому по умолчанию берётся атрибут queryset или model класса представления. Часто метод get_queryset() переопределяют, чтобы динамически изменять набор объектов, например, в зависимости от текущего пользователя или исключая будущие публикации в блоге.

MultipleObjectMixin также переопределяет get_context_data(), добавляя в контекст соответствующие переменные для разбиения на страницы (и пустые значения, если разбиение отключено). Для этого ей требуется именованный аргумент object_list, который передаёт ListView.

Для формирования TemplateResponse ListView затем использует MultipleObjectTemplateResponseMixin; как и упомянутая выше SingleObjectTemplateResponseMixin, она переопределяет get_template_names(), чтобы предоставить a range of options. Чаще всего используется <app_label>/<model_name>_list.html, а часть _list снова берётся из атрибута template_name_suffix. (Универсальные представления для работы с датами используют суффиксы, например _archive, _archive_year и так далее, чтобы применять разные шаблоны для специализированных представлений списков, связанных с датами.)

Использование SingleObjectMixin с View

Если мы хотим написать представление на основе классов, которое отвечает только на POST, мы создадим подкласс View и напишем в нём метод post(). Однако, если мы хотим, чтобы наша обработка выполнялась для конкретного объекта, определяемого по URL, нам понадобится функциональность, предоставляемая SingleObjectMixin.

Мы продемонстрируем это на примере модели Author, которую использовали во введении в универсальные представления на основе классов.

from django.http import HttpResponseForbidden, HttpResponseRedirect
from django.urls import reverse
from django.views import View
from django.views.generic.detail import SingleObjectMixin
from books.models import Author


class RecordInterestView(SingleObjectMixin, View):
    """Records the current user's interest in an author."""

    model = Author

    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()

        # Look up the author we're interested in.
        self.object = self.get_object()
        # Actually record interest somehow here!

        return HttpResponseRedirect(
            reverse("author-detail", kwargs={"pk": self.object.pk})
        )

На практике, вероятно, стоило бы сохранять сведения об интересе в хранилище типа «ключ — значение», а не в реляционной базе данных, поэтому эту часть мы опустили. Единственная часть представления, которой нужно использовать SingleObjectMixin, — это поиск интересующего нас автора, который выполняется вызовом self.get_object(). Обо всём остальном позаботится примесь.

Подключить это к нашим URL довольно просто:

from django.urls import path
from books.views import RecordInterestView

urlpatterns = [
    # ...
    path(
        "author/<int:pk>/interest/",
        RecordInterestView.as_view(),
        name="author-interest",
    ),
]

Обратите внимание на именованную группу pk, которую get_object() использует для поиска экземпляра Author. Можно также использовать slug или любую другую возможность SingleObjectMixin.

Использование SingleObjectMixin с ListView

ListView поддерживает встроенное разбиение на страницы, но иногда требуется разбить на страницы список объектов, связанных (внешним ключом) с другим объектом. В нашем примере с издательством можно разбить на страницы все книги определённого издателя.

Один из способов — объединить ListView с SingleObjectMixin, чтобы queryset списка книг, разбитого на страницы, формировался на основе издателя, найденного как единственный объект. Для этого нам понадобятся два разных queryset:

Book queryset for use by ListView

Поскольку нам доступен Publisher, книги которого нужно вывести, мы переопределяем get_queryset() и используем менеджер обратной связи внешнего ключа для Publisher.

Publisher queryset for use in get_object()

Мы воспользуемся стандартной реализацией get_object(), чтобы получить нужный объект Publisher. Однако нам нужно явно передать аргумент queryset, иначе стандартная реализация get_object() вызовет get_queryset(), который мы переопределили так, чтобы он возвращал объекты Book вместо объектов Publisher.

Теперь можно написать новое PublisherDetailView:

from django.views.generic import ListView
from django.views.generic.detail import SingleObjectMixin
from books.models import Publisher


class PublisherDetailView(SingleObjectMixin, ListView):
    paginate_by = 2
    template_name = "books/publisher_detail.html"

    def get(self, request, *args, **kwargs):
        self.object = self.get_object(queryset=Publisher.objects.all())
        return super().get(request, *args, **kwargs)

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["publisher"] = self.object
        return context

    def get_queryset(self):
        return self.object.book_set.all()

Обратите внимание, что мы задаём self.object внутри get(), чтобы позднее повторно использовать его в get_context_data() и get_queryset(). Если не задать template_name, будет использован стандартный шаблон ListView, которым в данном случае станет "books/book_list.html", поскольку это список книг; ListView ничего не знает о SingleObjectMixin и поэтому не может определить, что это представление связано с Publisher.

В примере намеренно используется небольшое значение paginate_by, чтобы для проверки разбиения на страницы не пришлось создавать много книг! Вот шаблон, который можно использовать:

{% extends "base.html" %}

{% block content %}
    <h2>Publisher {{ publisher.name }}</h2>

    <ol>
      {% for book in page_obj %}
        <li>{{ book.title }}</li>
      {% endfor %}
    </ol>

    <div class="pagination">
        <span class="step-links">
            {% if page_obj.has_previous %}
                <a href="?page={{ page_obj.previous_page_number }}">previous</a>
            {% endif %}

            <span class="current">
                Page {{ page_obj.number }} of {{ paginator.num_pages }}.
            </span>

            {% if page_obj.has_next %}
                <a href="?page={{ page_obj.next_page_number }}">next</a>
            {% endif %}
        </span>
    </div>
{% endblock %}

Использование FormMixin с DetailView

Вспомните наш предыдущий пример совместного использования View и SingleObjectMixin. Мы записывали заинтересованность пользователя в определённом авторе; теперь предположим, что мы хотим позволить ему оставить сообщение с объяснением, почему тот ему нравится. И снова предположим, что мы не собираемся хранить эти данные в реляционной базе данных, а используем для этого нечто более экзотическое, подробности которого здесь не важны.

На этом этапе вполне естественно обратиться к форме Form, чтобы инкапсулировать информацию, отправленную из браузера пользователя в Django. Предположим также, что мы активно используем REST и поэтому хотим использовать один и тот же URL для отображения автора и получения сообщения от пользователя. Перепишем наш AuthorDetailView, чтобы реализовать это.

Мы сохраним обработку GET из DetailView, хотя нам придётся добавить Form в контекстные данные, чтобы отобразить её в шаблоне. Также нам понадобится обработка формы из FormMixin и немного кода, чтобы форма корректно вызывалась при POST.

Наше новое AuthorDetailView выглядит так:

# CAUTION: you almost certainly do not want to do this.
# It is provided as part of a discussion of problems you can
# run into when combining different generic class-based view
# functionality that is not designed to be used together.

from django import forms
from django.http import HttpResponseForbidden
from django.urls import reverse
from django.views.generic import DetailView
from django.views.generic.edit import FormMixin
from books.models import Author


class AuthorInterestForm(forms.Form):
    message = forms.CharField()


class AuthorDetailView(FormMixin, DetailView):
    model = Author
    form_class = AuthorInterestForm

    def get_success_url(self):
        return reverse("author-detail", kwargs={"pk": self.object.pk})

    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()
        self.object = self.get_object()
        form = self.get_form()
        if form.is_valid():
            return self.form_valid(form)
        else:
            return self.form_invalid(form)

    def form_valid(self, form):
        # Here, we would record the user's interest using the message
        # passed in form.cleaned_data['message']
        return super().form_valid(form)

get_success_url() предоставляет место для перенаправления, которое используется в реализации form_valid() по умолчанию. Как отмечалось ранее, нам придётся реализовать собственный post().

Лучшее решение

Количество тонких взаимодействий между FormMixin и DetailView уже проверяет наши способности управлять сложностью. Вряд ли вам захочется писать такой класс самостоятельно.

В этом случае можно самостоятельно написать метод post(), оставив DetailView единственной обобщённой функциональностью, хотя написание кода обработки Form приведёт к большому количеству дублирования.

Другой вариант — создать отдельное представление для обработки формы. Это всё равно потребует меньше работы, чем описанный выше подход, и позволит без проблем использовать FormView отдельно от DetailView.

Ещё один лучший вариант

На самом деле мы пытаемся использовать два разных представления на основе классов с одним и тем же URL. Так почему бы просто так и не сделать? Здесь разделение очевидно: запросы GET должны получать DetailView (с добавленной в контекстные данные формой Form), а запросы POST должны получать FormView. Сначала настроим эти представления.

Представление AuthorDetailView почти такое же, как в первоначальном примере с AuthorDetailView; нам нужно написать собственный get_context_data(), чтобы сделать AuthorInterestForm доступным для шаблона. Для ясности мы опустим переопределение get_object() из предыдущего примера:

from django import forms
from django.views.generic import DetailView
from books.models import Author


class AuthorInterestForm(forms.Form):
    message = forms.CharField()


class AuthorDetailView(DetailView):
    model = Author

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["form"] = AuthorInterestForm()
        return context

Затем AuthorInterestFormView будет представлением FormView, но нам понадобится подключить SingleObjectMixin, чтобы найти нужного нам автора. Также не забудем установить template_name, чтобы ошибки формы отображались в том же шаблоне, который использует AuthorDetailView при GET:

from django.http import HttpResponseForbidden
from django.urls import reverse
from django.views.generic import FormView
from django.views.generic.detail import SingleObjectMixin


class AuthorInterestFormView(SingleObjectMixin, FormView):
    template_name = "books/author_detail.html"
    form_class = AuthorInterestForm
    model = Author

    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()
        self.object = self.get_object()
        return super().post(request, *args, **kwargs)

    def get_success_url(self):
        return reverse("author-detail", kwargs={"pk": self.object.pk})

Наконец, объединим всё это в новом представлении AuthorView. Мы уже знаем, что вызов as_view() для представления на основе класса даёт нам объект, который ведёт себя точно так же, как представление на основе функции. Поэтому мы можем вызвать его в месте, где выбираем одно из двух вложенных представлений.

В as_view() можно передавать именованные аргументы так же, как и в URLconf. Например, если вы хотите, чтобы поведение AuthorInterestFormView было доступно и по другому URL, но с использованием другого шаблона:

from django.views import View


class AuthorView(View):
    def get(self, request, *args, **kwargs):
        view = AuthorDetailView.as_view()
        return view(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        view = AuthorInterestFormView.as_view()
        return view(request, *args, **kwargs)

Этот подход можно использовать и с любыми другими обобщёнными представлениями на основе классов, а также с собственными представлениями на основе классов, непосредственно наследующимися от View или TemplateView, поскольку он позволяет максимально разделить представления.