• 3.2
  • 5.0
  • 6.1
  • Версия документации: 3.1

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

Некоторые из встроенных представлений 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,
        }),
    ]

Note, the snippet assumes your MEDIA_URL has a value of '/media/'. This will call the serve() view, passing in the path from the URLconf and the (required) document_root parameter.

Поскольку определение этого шаблона 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-адрес, который привел к ошибке, и «исключение», которое является полезным представлением исключения, которое вызвало представление (например, содержащее любое сообщение, переданное конкретному экземпляру «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 и отображается с пустым контекстом, чтобы уменьшить вероятность дополнительных ошибок.

Если для 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.

This view loads and renders the template 403.html in your root template directory, or if this file does not exist, instead serves the text «403 Forbidden», as per RFC 7231 Section 6.5.3 (the HTTP 1.1 Specification). The template context contains exception, which is the string representation of the exception that triggered the view.

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.

Back to Top