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

Некоторые встроенные представления Django документированы в Написании представлений, а также в других разделах документации.

Обслуживание файлов в режиме разработки

static.serve(request, path, document_root, show_indexes=False)

Возможно, помимо статических ресурсов вашего проекта, для удобства вы хотите, чтобы Django обслуживал их в локальной разработке. Представление serve() может использоваться для обслуживания любого каталога. (Это представление не предназначено для использования в производственной среде и должно использоваться только в качестве средства разработки; для обслуживания этих файлов в производственной среде следует использовать реальный веб-сервер frontend).

Наиболее вероятный пример — содержимое, загруженное пользователем, в 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 Запрещено», в соответствии с 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.