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

Представление — это вызываемый объект, который принимает запрос и возвращает ответ. Это может быть не только функция, 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, когда была опубликована последняя книга.

В URLconf мы сопоставляем URL-адрес с представлением списка книг:

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