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

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