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

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