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

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

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

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

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

Наиболее вероятный пример — это загруженные пользователем данные в MEDIA_ROOT. django.contrib.staticfiles предназначен для статических ресурсов и не имеет встроенной обработки загруженных пользователем файлов, но вы можете настроить Django на обслуживание ваших MEDIA_ROOT путем добавления чего-то подобного в вашу конфигурацию URL:

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 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.