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

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 в подклассе на что-то другое. (Например, generic edit views использует _form для представлений create и update, и _confirm_delete для представлений 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 с View¶

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

Мы продемонстрируем это на примере модели Author, которую мы использовали в generic class-based views introduction.

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, чтобы кверисет для постраничного списка книг мог зависеть от издателя, найденного как единый объект. Для этого нам нужно иметь два разных кверисета:

Book queryset для использования ListView

Поскольку у нас есть доступ к Publisher, чьи книги мы хотим перечислить, мы переопределяем get_queryset() и используем Publisher из reverse foreign key manager.

Publisher queryset для использования в 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 почти такой же, как when we first introduced 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, поскольку он позволяет максимально разделить различные представления.