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

Некоторые из встроенных представлений 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,
        }),
    ]

Note, the snippet assumes your MEDIA_URL has a value of 'media/'. This will call the serve() view, passing in the path from the URLconf and the (required) document_root parameter.

Поскольку определение этого шаблона 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.

This view loads and renders the template 403.html in your root template directory, or if this file does not exist, instead serves the text «403 Forbidden», as per RFC 9110#section-15.5.4 (the HTTP 1.1 Specification). The template context contains exception, which is the string representation of the exception that triggered the view.

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 также используются только в том случае, если DEBUG имеет значение False.

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