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

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

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

static.serve( Запрос , путь , 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() , передавая ему путь, указанный в конфигурации URL-адреса, и параметр (обязательно) document_root .

Поскольку определение этого шаблона URL-адреса может быстро стать громоздким, Django поставляется с небольшой служебной функцией URL-адреса с именем static() , которая принимает префикс (например, MEDIA_URL ) в качестве параметра и путь к просмотру точки в точке, например 'django.views.static.serve' . Любой другой параметр функции прозрачно передается в представление.

Просмотр ошибок

Django имеет несколько представлений по умолчанию для обработки ошибок HTTP. Чтобы заменить их собственными пользовательскими представлениями, см. Настройка представлений ошибок .

Просмотр 404 (страница не найдена)

defaults.page_not_found( запрос , исключение , template_name = '404.html' )

Когда вы генерируете исключение Http404 из представления, Django загружает специальное представление, предназначенное для обработки ошибок 404. По умолчанию это представление, django.views.defaults.page_not_found() которое либо выдает сообщение «Не найдено», либо загружает и отображает шаблон. 404.html если он существует в корневом каталоге шаблонов.

Представление 404 по умолчанию передаст в шаблон две переменные:, request_path который является URL-адресом, который привел к ошибке, и exception который является полезным представлением исключения, которое вызвало представление (например, содержащее возможное сообщение передается Http404 конкретному экземпляру ).

Три вещи, которые следует отметить при просмотре 404:

  • Представление 404 также вызывается, если Django не находит совпадения после проверки каждого регулярного выражения в конфигурации URL.
  • Представление 404 принимает объект RequestContext и может обращаться к переменным, созданным обработчиками контекста шаблона (например MEDIA_URL ).
  • Если DEBUG установлено значение True (в вашем модуле настроек), представление 404 никогда не будет использоваться, но будет заменено отображением конфигурации URL-адреса, а также некоторой отладочной информации.

Просмотр 500 (ошибка сервера)

defaults.server_error( запрос , 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( запрос , исключение , template_name = '403.html' )

В той же перспективе, что и для представлений 404 и 500, Django содержит представление для обработки ошибок 403 отказа в доступе. Если представление выдает исключение 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( Запрос , исключение , TEMPLATE_NAME = '400.html' )

Когда SuspiciousOperation в Django генерируется исключение , оно может быть обработано компонентом Django (например, путем сброса данных сеанса). Когда это не так, Django считает текущий запрос «плохим запросом» вместо того, чтобы вывести ошибку сервера.

django.views.defaults.bad_request в целом очень похож на представление server_error , но возвращает код состояния 400, указывающий, что состояние ошибки является результатом операции клиента. По умолчанию ничего из исключения, которое инициировало представление, не передается в контекст шаблона, поскольку сообщение об исключении может содержать конфиденциальную информацию, такую ​​как пути к файловой системе.

Просмотры bad_request также используются только тогда, когда они того DEBUG стоят False .

Copyright ©2021 All rights reserved