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

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

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

Представление 403 (HTTP Запрещено)

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 7231#section-6.5.3 (Спецификация 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 также используются только при значении DEBUG False.