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

Встроенные представления Django на основе классов предоставляют много функциональности, но некоторые из них можно использовать отдельно. Например, вы можете написать представление, которое отображает шаблон для создания ответа HTTP, но вы не можете использовать TemplateView; возможно, вам нужно отобразить шаблон только в POST, при этом GET выполняет совершенно иную задачу. Хотя вы могли бы использовать TemplateResponse напрямую, это, скорее всего, приведёт к дублированию кода.

По этой причине Django также предоставляет ряд миксинов, которые предоставляют более дискретную функциональность. Например, отображение шаблона инкапсулировано в TemplateResponseMixin. Документация к Django содержит полную документацию по всем миксинам.

Контекст и ответы шаблонов

Предоставляются два центральных миксина, которые помогают обеспечить согласованный интерфейс для работы с шаблонами в представлениях на основе классов.

TemplateResponseMixin

Каждое встроенное представление, которое возвращает TemplateResponse, будет вызывать метод render_to_response(), который TemplateResponseMixin предоставляет. В большинстве случаев это будет вызываться автоматически (например, это вызывается методом get(), реализованным как TemplateView, так и DetailView); аналогично, вам, скорее всего, не придётся переопределять его, хотя если вы хотите, чтобы ваш ответ возвращал что-то, что не отображается с помощью шаблона Django, вам нужно будет это сделать. Пример этого см. в примере JSONResponseMixin.

render_to_response() сам вызывает get_template_names(), который по умолчанию ищет template_name в представлении на основе класса; два других миксина (SingleObjectTemplateResponseMixin и MultipleObjectTemplateResponseMixin) переопределяют его, чтобы предоставить более гибкие значения по умолчанию при работе с фактическими объектами.

ContextMixin

Каждое встроенное представление, которому нужны данные контекста, например, для отображения шаблона (включая TemplateResponseMixin выше), должно вызывать get_context_data(), передавая любые данные, которые они хотят включить, в качестве именованных аргументов. get_context_data() возвращает словарь; в ContextMixin он возвращает свои именованные аргументы, но обычно это переопределяется для добавления большего числа элементов в словарь. Также можно использовать атрибут extra_context.

Создание представлений Django на основе классов

Давайте посмотрим, как два общих представления Django на основе классов создаются из миксинов, предоставляющих дискретную функциональность. Рассмотрим DetailView, который отображает «детальную» информацию об объекте, и ListView, который отображает список объектов, обычно из набора запросов, и необязательно их разделяет на страницы. Это позволит нам познакомиться с четырьмя миксинами, которые вместе обеспечивают полезную функциональность при работе как с одним объектом Django, так и с несколькими объектами.

Также есть миксины, участвующие в общих представлениях редактирования (FormView, и модели-специфические представления CreateView, UpdateView и DeleteView), а также в представлениях, основанных на датах. Они описаны в документации по миксинам.

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

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

Теперь, когда мы увидели, как обобщенные представления Django на основе классов используют предоставленные миксины, давайте рассмотрим другие способы их комбинирования. Конечно, мы все еще будем комбинировать их либо со встроенными представлениями на основе классов, либо с другими обобщенными представлениями на основе классов, но есть ряд более редких проблем, которые вы можете решить, чем предоставляет Django по умолчанию.

Использование 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 RecordInterest(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 RecordInterest

urlpatterns = [
    #...
    path('author/<int:pk>/interest/', RecordInterest.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.

Теперь мы можем написать новую PublisherDetail:

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

class PublisherDetail(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 %}

Избегайте чего-либо более сложного

В целом, вы можете использовать TemplateResponseMixin и SingleObjectMixin, когда вам нужна их функциональность. Как показано выше, при некоторой внимательности вы даже можете объединить SingleObjectMixin с ListView. Однако, по мере попытки сделать это, вещи становятся все более сложными, и хорошее правило — это:

Чтобы показать, что происходит, когда вы пытаетесь сделать что-то более сложное, мы покажем пример, который жертвует удобочитаемостью и поддерживаемостью, когда есть более простое решение. Сначала рассмотрим неудачную попытку объединить DetailView с FormMixin, чтобы позволить нам POST Django Form в том же URL, что и отображение объекта с помощью DetailView.

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

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

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

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

Наш новый AuthorDetail выглядит так:

# 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 AuthorDetail(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.

Вид AuthorDisplay почти такой же, как когда мы впервые представили AuthorDetail; мы должны написать собственную 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 AuthorDisplay(DetailView):
    model = Author

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

Затем AuthorInterest является FormView, но мы должны включить SingleObjectMixin, чтобы мы могли найти автора, о котором говорим, и мы должны помнить, что установить template_name , чтобы ошибки формы отображались в том же шаблоне, что и AuthorDisplay использует в 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 AuthorInterest(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})

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

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

from django.views import View

class AuthorDetail(View):

    def get(self, request, *args, **kwargs):
        view = AuthorDisplay.as_view()
        return view(request, *args, **kwargs)

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

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

Больше, чем просто HTML

Преимущества представлений на основе классов проявляются, когда вам нужно делать одно и то же многократно. Предположим, вы пишете API, и каждое представление должно возвращать JSON вместо рендеринга HTML.

Мы можем создать класс-микшин для использования во всех наших представлениях, обрабатывая преобразование в JSON один раз.

Например, миксин JSON может выглядеть примерно так:

from django.http import JsonResponse

class JSONResponseMixin:
    """
    A mixin that can be used to render a JSON response.
    """
    def render_to_json_response(self, context, **response_kwargs):
        """
        Returns a JSON response, transforming 'context' to make the payload.
        """
        return JsonResponse(
            self.get_data(context),
            **response_kwargs
        )

    def get_data(self, context):
        """
        Returns an object that will be serialized as JSON by json.dumps().
        """
        # Note: This is *EXTREMELY* naive; in reality, you'll need
        # to do much more complex handling to ensure that arbitrary
        # objects -- such as Django model instances or querysets
        # -- can be serialized as JSON.
        return context

Этот миксин предоставляет метод render_to_json_response() с той же сигнатурой, что и render_to_response(). Для его использования нам нужно добавить его в TemplateView например, и переопределить render_to_response() , чтобы вызвать render_to_json_response() вместо него:

from django.views.generic import TemplateView

class JSONView(JSONResponseMixin, TemplateView):
    def render_to_response(self, context, **response_kwargs):
        return self.render_to_json_response(context, **response_kwargs)

Аналогично, мы можем использовать наш миксин с одним из представлений на основе классов. Мы можем создать собственную версию DetailView, смешав JSONResponseMixin с django.views.generic.detail.BaseDetailView — (поведение DetailView до рендеринга шаблона было смешано):

from django.views.generic.detail import BaseDetailView

class JSONDetailView(JSONResponseMixin, BaseDetailView):
    def render_to_response(self, context, **response_kwargs):
        return self.render_to_json_response(context, **response_kwargs)

Это представление можно развернуть так же, как и любое другое DetailView, с абсолютно таким же поведением — за исключением формата ответа.

Если вы хотите быть действительно смелым, вы можете даже смешать подкласс DetailView, который может возвращать и HTML, и JSON-контент, в зависимости от некоторых свойств HTTP-запроса, таких как аргумент запроса или HTTP-заголовок. Смешайте как JSONResponseMixin , так и SingleObjectTemplateResponseMixin, и переопределите реализацию render_to_response() , чтобы перенаправить к соответствующему методу рендеринга в зависимости от типа ответа, который пользователь запросил:

from django.views.generic.detail import SingleObjectTemplateResponseMixin

class HybridDetailView(JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView):
    def render_to_response(self, context):
        # Look for a 'format=json' GET argument
        if self.request.GET.get('format') == 'json':
            return self.render_to_json_response(context)
        else:
            return super().render_to_response(context)

Из-за того, как Python обрабатывает перегрузку методов, вызов super().render_to_response(context) в конечном итоге вызывает реализацию render_to_response() в TemplateResponseMixin.