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

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