Базовые представления на основе классов

Представление — это вызываемый объект, который принимает запрос и возвращает ответ. Это может быть не только функция, и Django предоставляет примеры классов, которые могут использоваться в качестве представлений. Они позволяют структурировать представления и повторно использовать код, используя наследование и миксины. Также существуют некоторые универсальные представления для задач, о которых мы поговорим позже, но вы можете разработать собственную структуру повторно используемых представлений, подходящую для вашего случая. Подробную информацию см. в документации по представлениям на основе классов.

• Введение в представления на основе классов
• Встроенные универсальные представления на основе классов
• Обработка форм с представлениями на основе классов
• Использование миксинов с представлениями на основе классов

Основные примеры

Django предоставляет базовые классы представлений, подходящие для широкого спектра применений. Все представления наследуются от класса View, который отвечает за связывание представления с URL-адресами, обработку запросов различных HTTP-методов и другие общие функции. RedirectView обеспечивает переадресацию HTTP, а TemplateView расширяет базовый класс, чтобы он также мог рендерить шаблон.

Использование в вашем URLconf

Самый прямой способ использования универсальных представлений — это создание их непосредственно в вашем URLconf. Если вы только изменяете несколько атрибутов представления на основе класса, вы можете передать их в вызов метода as_view():

from django.urls import path
from django.views.generic import TemplateView

urlpatterns = [
    path("about/", TemplateView.as_view(template_name="about.html")),
]

Любые аргументы, переданные методу as_view(), переопределят атрибуты, заданные в классе. В этом примере мы устанавливаем template_name для TemplateView. Аналогичный подход переопределения можно использовать для атрибута url в классе RedirectView.

Наследование от универсальных представлений

Второй, более мощный способ использования универсальных представлений — это наследование от существующего представления и переопределение атрибутов (например, template_name) или методов (например, get_context_data) в вашем подклассе, чтобы предоставить новые значения или методы. Рассмотрим, к примеру, представление, которое просто отображает один шаблон, about.html. Django имеет универсальное представление для этого — TemplateView — поэтому мы можем создать его подкласс и переопределить имя шаблона:

# some_app/views.py
from django.views.generic import TemplateView


class AboutView(TemplateView):
    template_name = "about.html"

Затем нам нужно добавить это новое представление в наш URLconf. TemplateView — это класс, а не функция, поэтому мы указываем URL-адрес на метод класса as_view(), который предоставляет функциональный доступ к представлениям на основе классов:

# urls.py
from django.urls import path
from some_app.views import AboutView

urlpatterns = [
    path("about/", AboutView.as_view()),
]

Для получения дополнительной информации о том, как использовать встроенные универсальные представления, обратитесь к следующему разделу о универсальных представлениях на основе классов.

Поддержка других HTTP-методов

Предположим, кто-то хочет получить доступ к нашей библиотеке книг через HTTP, используя представления в качестве API. Клиент API будет время от времени подключаться и загружать данные о книгах, опубликованных с момента последнего посещения. Но если с тех пор новых книг не появилось, это пустая трата времени процессора и пропускной способности для извлечения книг из базы данных, рендеринга полного ответа и отправки его клиенту. Возможно, было бы предпочтительнее спросить API, когда была опубликована последняя книга.

Мы отображаем URL-адрес списка книг в URLconf:

from django.urls import path
from books.views import BookListView

urlpatterns = [
    path("books/", BookListView.as_view()),
]

И представление:

from django.http import HttpResponse
from django.views.generic import ListView
from books.models import Book


class BookListView(ListView):
    model = Book

    def head(self, *args, **kwargs):
        last_book = self.get_queryset().latest("publication_date")
        response = HttpResponse(
            # RFC 1123 date format.
            headers={
                "Last-Modified": last_book.publication_date.strftime(
                    "%a, %d %b %Y %H:%M:%S GMT"
                )
            },
        )
        return response

Если к представлению обращаются по запросу GET, в ответ возвращается список объектов (с использованием шаблона book_list.html). Но если клиент отправляет запрос HEAD, в ответе отсутствует тело, а заголовок Last-Modified указывает, когда была опубликована последняя книга. На основе этой информации клиент может или не может загружать весь список объектов.

Асинхронные представления на основе классов

Помимо уже показанных синхронных (def) обработчиков методов, подклассы View могут определять асинхронные (async def) обработчики методов для использования асинхронного кода с помощью await:

import asyncio
from django.http import HttpResponse
from django.views import View


class AsyncView(View):
    async def get(self, request, *args, **kwargs):
        # Perform io-blocking view logic using await, sleep for example.
        await asyncio.sleep(1)
        return HttpResponse("Hello async world!")

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

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