Spec-Zone.ru › Django 1.10

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

Некоторые встроенные представления 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, 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 с некоторой отладочной информацией.
Изменено в Django 1.9:

Изменилась сигнатура page_not_found(). Функция теперь принимает второй параметр — исключение, которое вызвало ошибку. Полезное представление исключения также передаётся в контекст шаблона.

Изменено в Django 1.10:

Передача несуществующего template_name вызовет TemplateDoesNotExist.

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

Изменено в Django 1.10:

Передача несуществующего template_name вызовет TemplateDoesNotExist.

Представление 403 (запрещено HTTP)

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
    # ...
Изменено в Django 1.9:

Изменилась сигнатура permission_denied() в Django 1.9. Функция теперь принимает второй параметр — исключение, которое вызвало ошибку. Строковое представление исключения также передаётся в контекст шаблона.

Изменено в Django 1.10:

Передача несуществующего template_name вызовет TemplateDoesNotExist.

Представление 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.

Изменено в Django 1.9:

Изменилась сигнатура bad_request() в Django 1.9. Функция теперь принимает второй параметр — исключение, которое вызвало ошибку.

Изменено в Django 1.10:

Передача несуществующего template_name вызовет TemplateDoesNotExist.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.10/ref/views/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API