Простые примеры¶

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

Использование CBV в ваших 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.

Использование общих классов-представлений в наследовании¶

Второй, более мощный и гибкий способ использования общих CBV, это использование их в качестве родительских классов. Вы можете указать эти классы в качестве родительских для вашего пользовательского класса-представления и переопределить в теле вашего класса значения атрибутов (таких как 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()),
]

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

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

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

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