Spec-Zone.ru › Django 4.2

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

Следующие три класса предоставляют большую часть функциональности, необходимой для создания представлений Django. Можно рассматривать их как родительские представления, которые можно использовать самостоятельно или наследовать от них. Возможно, они не предоставляют всех необходимых возможностей для проектов, в этом случае существуют Mixins и обобщенные представления на основе классов.

Многие встроенные представления Django на основе классов наследуются от других представлений на основе классов или различных mixins. Поскольку эта цепочка наследования очень важна, родительские классы документированы в разделе Предки (Порядок разрешения методов). MRO — это аббревиатура от Method Resolution Order.

View

class django.views.generic.base.View

Базовый класс представления. Все остальные представления на основе классов наследуются от этого базового класса. Это не строго обобщенное представление и поэтому также может быть импортировано из django.views.

Диаграмма потока методов

  1. setup()
  2. dispatch()
  3. http_method_not_allowed()
  4. options()

Пример views.py:

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


class MyView(View):
    def get(self, request, *args, **kwargs):
        return HttpResponse("Hello, World!")

Пример urls.py:

from django.urls import path

from myapp.views import MyView

urlpatterns = [
    path("mine/", MyView.as_view(), name="my-view"),
]

Атрибуты

http_method_names

Список имен HTTP-методов, которые будет принимать это представление.

По умолчанию:

["get", "post", "put", "patch", "delete", "head", "options", "trace"]

Методы

classmethod as_view(**initkwargs)

Возвращает вызываемое представление, которое принимает запрос и возвращает ответ:

response = MyView.as_view()(request)

Возвращаемое представление имеет view_class и view_initkwargs атрибуты.

При вызове представления во время цикла запрос/ответ метод setup() присваивает HttpRequest атрибуту представления request, а любые позиционные и/или ключевые аргументы, извлеченные из шаблона URL, соответственно атрибутам args и kwargs. Затем вызывается dispatch().

Если подкласс View определяет обработчики асинхронных (async def) методов, as_view() отметит возвращаемое вызываемое значение как функцию-генератор. Исключение ImproperlyConfigured будет поднято, если асинхронные (async def) и синхронные (def) обработчики определены в одном классе представления.

Изменено в Django 4.1:

Была добавлена поддержка асинхронных (async def) обработчиков методов.

setup(request, *args, **kwargs)

Выполняет ключевую инициализацию представления перед вызовом dispatch().

При переопределении этого метода необходимо вызвать super().

dispatch(request, *args, **kwargs)

Часть представления, которая принимает аргумент view плюс аргументы и возвращает HTTP-ответ.

По умолчанию реализация анализирует HTTP-метод и пытается делегировать его методу, соответствующему HTTP-методу; метод GET будет делегирован методу get(), а метод POST — методу post(), и так далее.

По умолчанию запрос HEAD будет делегирован методу get(). Если вам нужно обработать запросы HEAD другим способом, чем GET, можно переопределить метод head(). См. Поддержка других HTTP-методов для примера.

http_method_not_allowed(request, *args, **kwargs)

Если представление вызывается с HTTP-методом, который оно не поддерживает, вызывается этот метод вместо него.

По умолчанию реализация возвращает HttpResponseNotAllowed со списком разрешенных методов в виде обычного текста.

options(request, *args, **kwargs)

Обрабатывает ответы на запросы для HTTP-метода OPTIONS. Возвращает ответ с заголовком Allow, содержащим список разрешенных HTTP-методов представления.

Если другие обработчики HTTP-методов в классе являются асинхронными (async def), то ответ будет обернут в функцию-генератор для использования с await.

Изменено в Django 4.1:

Была добавлена поддержка классов, определяющих асинхронные (async def) обработчики методов.

TemplateView

class django.views.generic.base.TemplateView

Отображает заданный шаблон с контекстом, содержащим параметры, извлеченные из URL.

Предки (Порядок разрешения методов)

Это представление наследует методы и атрибуты от следующих представлений:

  • django.views.generic.base.TemplateResponseMixin
  • django.views.generic.base.ContextMixin
  • django.views.generic.base.View

Диаграмма потока методов

  1. setup()
  2. dispatch()
  3. http_method_not_allowed()
  4. get_context_data()

Пример views.py:

from django.views.generic.base import TemplateView

from articles.models import Article


class HomePageView(TemplateView):
    template_name = "home.html"

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["latest_articles"] = Article.objects.all()[:5]
        return context

Пример urls.py:

from django.urls import path

from myapp.views import HomePageView

urlpatterns = [
    path("", HomePageView.as_view(), name="home"),
]

Контекст

  • Заполняется (через ContextMixin) ключевыми аргументами, извлеченными из шаблона URL, который обслужил представление.
  • Вы также можете добавить контекст, используя ключевое слово extra_context для as_view().

RedirectView

class django.views.generic.base.RedirectView

Перенаправляет на заданный URL.

Указанный URL может содержать форматирование строк в стиле словаря, которое будет интерполироваться по отношению к параметрам, захваченным в URL. Поскольку интерполяция ключевых слов всегда выполняется (даже если аргументы не переданы), любые символы "%" в URL должны быть написаны как "%%" , чтобы Python преобразовывал их в один символ процента при выводе.

Если заданный URL является None, Django вернёт HttpResponseGone (410).

Предки (MRO)

Этот вид наследует методы и атрибуты от следующего вида:

  • django.views.generic.base.View

Схема потока метода

  1. setup()
  2. dispatch()
  3. http_method_not_allowed()
  4. get_redirect_url()

Пример views.py:

from django.shortcuts import get_object_or_404
from django.views.generic.base import RedirectView

from articles.models import Article


class ArticleCounterRedirectView(RedirectView):
    permanent = False
    query_string = True
    pattern_name = "article-detail"

    def get_redirect_url(self, *args, **kwargs):
        article = get_object_or_404(Article, pk=kwargs["pk"])
        article.update_counter()
        return super().get_redirect_url(*args, **kwargs)

Пример urls.py:

from django.urls import path
from django.views.generic.base import RedirectView

from article.views import ArticleCounterRedirectView, ArticleDetailView

urlpatterns = [
    path(
        "counter/<int:pk>/",
        ArticleCounterRedirectView.as_view(),
        name="article-counter",
    ),
    path("details/<int:pk>/", ArticleDetailView.as_view(), name="article-detail"),
    path(
        "go-to-django/",
        RedirectView.as_view(url="https://www.djangoproject.com/"),
        name="go-to-django",
    ),
]

Атрибуты

url

URL для перенаправления в виде строки. Или None для поднятия HTTP-ошибки 410 (Gone).

pattern_name

Имя шаблона URL для перенаправления. Обращение к URL будет выполнено с теми же аргументами и ключевыми аргументами, которые передаются для этого вида.

permanent

Является ли перенаправление постоянным. Единственное различие здесь — возвращаемый код HTTP-статуса. Если True, то перенаправление будет использовать код состояния 301. Если False, то перенаправление будет использовать код состояния 302. По умолчанию, permanent это False.

query_string

Следует ли передавать строку запроса GET в новое местоположение. Если True, тогда строка запроса добавляется к URL. Если False, тогда строка запроса отбрасывается. По умолчанию, query_string это False.

Методы

get_redirect_url(*args, **kwargs)

Строит целевой URL для перенаправления.

Аргументы args и kwargs являются позиционными и/или ключевыми аргументами захваченными из шаблона URL соответственно.

Реализация по умолчанию использует url в качестве начальной строки и выполняет расширение % именованных параметров в этой строке с использованием именованных групп, захваченных в URL.

Если url не задан, get_redirect_url() пытается выполнить обращение к pattern_name с использованием захваченных в URL данных (используются как именованные, так и безымянные группы).

Если это запрошено с помощью query_string, она также добавит строку запроса к сгенерированному URL. Подклассы могут реализовывать любое поведение, которое они пожелают, пока метод возвращает строку URL, готовую к перенаправлению.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/4.2/ref/class-based-views/base/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API