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

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 или 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 с представлением

Если мы хотим написать представление на основе класса, которое отвечает только на 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. Вы также можете использовать псевдоним или любые другие возможности SingleObjectMixin.

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

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

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

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, поэтому он не имеет ни малейшего представления, что это представление связано с издателем.

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, так как он сохраняет различные представления максимально независимыми.