Встроенные представления
Некоторые встроенные представления 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.views.static import serve
# ... the rest of your URLconf goes here ...
if settings.DEBUG:
urlpatterns += [
url(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(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 не находит соответствия после проверки всех регулярных выражений в конфигурации URL.
- Представлению 404 передаётся
RequestContext, и оно будет иметь доступ к переменным, предоставленным обработчиками контекста шаблонов (например,MEDIA_URL). - Если
DEBUGустановлено вTrue(в вашем файле настроек), то ваше представление 404 никогда не будет использоваться, и вместо него будет отображаться ваша конфигурация URL с некоторой отладочной информацией.
Подпись page_not_found() изменилась. Функция теперь принимает второй параметр — исключение, вызвавшее ошибку. Полезное представление исключения также передаётся в контекст шаблона.
Представление 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 Запрещено. Если в результате работы представления возникает исключение 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
# ...
Подпись permission_denied() изменилась в Django 1.9. Функция теперь принимает второй параметр — исключение, вызвавшее ошибку. Представление исключения в виде строки Юникод также передаётся в контекст шаблона.
Представление 400 (ошибка запроса)
-
defaults.bad_request(request, exception, template_name='400.html')
При возникновении исключения SuspiciousOperation в Django, оно может обрабатываться компонентом Django (например, для сброса данных сессии). Если оно не обрабатывается явно, Django будет рассматривать текущий запрос как «неверный запрос», а не ошибку сервера.
django.views.defaults.bad_request, в остальном очень похож на представление server_error , но возвращает код состояния 400, указывая, что условие ошибки было результатом действия клиента. По умолчанию ничего, относящегося к исключению, которое вызвало запуск представления, не передаётся в контекст шаблона, поскольку сообщение об исключении может содержать конфиденциальную информацию, например, пути к файлам.
Представления bad_request используются только в том случае, если DEBUG установлено в False.
Подпись bad_request() изменилась в Django 1.9. Функция теперь принимает второй параметр — исключение, вызвавшее ошибку.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.9/ref/views/