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

Некоторые встроенные представления 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.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(), передав путь из URLconf и (обязательный) параметр document_root.

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

Представления ошибок

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

Представление 404 (страница не найдена)

defaults.page_not_found(request, template_name='404.html')

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

По умолчанию представление 404 передаёт в шаблон одну переменную: request_path, которая представляет собой URL, приведший к ошибке.

Три момента относительно представлений 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, template_name='403.html')

В том же духе, что и представления 404 и 500, Django имеет представление для обработки ошибок 403 Forbidden. Если представление приводит к исключению 403, то Django по умолчанию вызовет представление django.views.defaults.permission_denied.

Это представление загружает и отображает шаблон 403.html в корневом каталоге шаблонов, или, если этот файл не существует, отображает текст «403 Forbidden», в соответствии с RFC 2616 (Спецификация HTTP 1.1).

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, template_name='400.html')

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

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

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