Встроенные функции представления

Некоторые из встроенных представлений Django задокументированы в Написание представлений, а также в других местах документации.

Обслуживание файлов при разработке

static.serve(request, path, document_root, show_indexes=False)

Помимо статических ресурсов вашего проекта могут быть файлы, которые для удобства вы бы хотели, чтобы Django обслуживал для вас при локальной разработке. Представление serve() может использоваться для обслуживания любого каталога, который вы ему предоставили. (Это представление не предназначено для производственного использования и должно использоваться только в качестве вспомогательного средства для разработки; вы должны использовать эти файлы в производственной среде, используя настоящий веб-сервер).

Наиболее вероятный пример - загруженный пользователем контент в MEDIA_ROOT. django.contrib.staticfiles предназначен для статических ресурсов и не имеет встроенной обработки для загруженных пользователем файлов, но вы можете настроить Django для обслуживания вашего MEDIA_ROOT, добавив что-то вроде этого в ваш URLconf:

from django.conf import settings
from django.urls import re_path
from django.views.static import serve

# ... the rest of your URLconf goes here ...

if settings.DEBUG:
    urlpatterns += [
        re_path(
            r"^media/(?P<path>.*)$",
            serve,
            {
                "document_root": settings.MEDIA_ROOT,
            },
        ),
    ]

Обратите внимание, в этом фрагменте предполагается, что ваш MEDIA_URL имеет значение 'media/'. Это вызовет представление serve(), передавая путь из URLconf и (обязательный) параметр document_root.

Поскольку определение этого шаблона URL может стать немного громоздким, Django поставляется с небольшой вспомогательной функцией URL static(), которая принимает в качестве параметров префикс, например MEDIA_URL и путь к представлению, например 'django.views.static.serve'. Любой другой параметр функции будет прозрачно передан в представление.

Представления для ошибок

Django по умолчанию имеет несколько представлений для обработки ошибок HTTP. Чтобы заменить их вашими собственными пользовательскими представлениями, смотрите Настройка представлений ошибок.

Прдеставление 404 (страница не найдена)

defaults.page_not_found(request, exception, template_name='404.html')

Когда вы вызываете Http404 из представления, Django загружает специальное представление, предназначенное для обработки ошибок 404. По умолчанию это представление django.views.defaults.page_not_found(), которое либо выдает сообщение «Not Found», либо загружает и отображает шаблон «404.html», если вы создали его в корневом каталоге шаблонов.

Представление 404 по умолчанию передаст в шаблон две переменные: `` request_path „“, который является URL-адресом, который привел к ошибке, и `` exception „“, который является полезным представлением исключения, вызвавшего представление (например, содержащего любое сообщение, переданное конкретному экземпляру Http404).

Три вещи, которые следует отметить при 404:

  • Представление 404 также вызывается, если Django не находит совпадения после проверки каждого регулярного выражения в URLconf.
  • Представлению 404 передается RequestContext и он будет иметь доступ к переменным, предоставленным процессорами контекста вашего шаблона (например, MEDIA_URL).
  • Если DEBUG установлен в True (в вашем модуле настроек), тогда ваше представление 404 никогда не будет использоваться, и вместо него будет отображаться ваш URLconf с некоторой отладочной информацией.

Представление 500 (ошибка сервера)

defaults.server_error(request, template_name='500.html')

Точно так же Django выполняет особый код в случае ошибок времени выполнения в коде представления. Если представление приводит к исключению, Django по умолчанию вызывает представление django.views.defaults.server_error, которое либо выдает сообщение об ошибке сервера, либо загружает и отображает шаблон 500.html, если вы создали его в корневом каталоге шаблонов.

Представление 500 по умолчанию не передает никаких переменных в шаблон 500.html и отображается с пустым контекстом, чтобы уменьшить вероятность дополнительных ошибок.

Если DEBUG установлен на True (в вашем модуле настроек), то ваше представление 500 никогда не будет использоваться, и вместо него будет отображаться трассировка с некоторой отладочной информацией.

403 (HTTP Forbidden)

defaults.permission_denied(request, exception, template_name='403.html')

В том же духе, что и представления 404 и 500, в Django есть представление для обработки 403 Forbidden. Если представление приводит к исключению 403, то Django по умолчанию вызывает представление django.views.defaults.permission_denied.

Это представление загружает и отображает шаблон 403.html в корневом каталоге шаблонов, а если такого файла не существует, то вместо него выдается текст «403 Forbidden», согласно RFC 9110#section-15.5.4 (спецификация HTTP 1.1). Контекст шаблона содержит exception, который является строковым представлением исключения, вызвавшего данное представление.

django.views.defaults.permission_denied запускается исключением PermissionDenied. Чтобы запретить доступ в представлении, вы можете использовать следующий код:

from django.core.exceptions import PermissionDenied


def edit(request, pk):
    if not request.user.is_staff:
        raise PermissionDenied
    # ...

400 (плохой запрос)

defaults.bad_request(request, exception, template_name='400.html')

Когда в Django вызывается SuspiciousOperation, он может обрабатываться компонентом Django (например, сбрасывать данные сеанса). Если не обрабатывать специально, Django будет рассматривать текущий запрос как «неверный запрос» вместо ошибки сервера.

django.views.defaults.bad_request в остальном очень похож на представление server_error, но возвращается с кодом состояния 400, указывающим, что состояние ошибки было результатом операции клиента. По умолчанию ничего, связанное с исключением, вызвавшим представление, не передается в контекст шаблона, поскольку сообщение об исключении может содержать конфиденциальную информацию, такую как пути к файловой системе.

Представления bad_request также используются только в том случае, если :setting:DEBUG имеет значение False.

Валидаторы
Мета-документация и разное
Вернуться на верх