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

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