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

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

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

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

Набор запросов Book для использования ListView

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

Набор запросов Publisher для использования в 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

Then the AuthorInterestForm is a FormView, but we have to bring in SingleObjectMixin so we can find the author we’re talking about, and we have to remember to set template_name to ensure that form errors will render the same template as AuthorDetailView is using on 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, поскольку он сохраняет различные представления как можно более отдельными.