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

Несколько встроенных представлений 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 Запрещено. Если представление приводит к исключению 403, Django по умолчанию вызовет представление django.views.defaults.permission_denied.

Это представление загружает и отображает шаблон 403.html в вашей корневой директории шаблонов, или если этот файл не существует, он вместо этого отображает текст «403 Запрещено», как указано в 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.