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

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

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 используются только тогда, когда DEBUG равно False.