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

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 ¶

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

Чтобы получить объекты, ListViewиспользует MultipleObjectMixin, который предоставляет как get_queryset() и paginate_queryset(). В отличие от with 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_listtemplate_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, чтобы набор запросов для разбитого на страницы списка книг мог зависнуть от издателя, найденного как единственный объект. Для этого нам нужно иметь два разных набора запросов:

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

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

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вместе. Мы фиксировали интерес пользователя к конкретному автору; скажите сейчас, что мы хотим, чтобы они оставили сообщение о том, почему они им нравятся. Опять же, давайте предположим, что мы собираемся хранить это не в реляционной базе данных, а в чем-то более эзотерическом, о чем мы не будем здесь беспокоиться.

На этом этапе естественно обратиться к a, 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

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