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

В Django 1.3 добавлена ​​структура, позволяющая использовать класс в качестве представления. Это означает, что вы можете составить представление из набора методов, которые можно разделить на подклассы и переопределить для обеспечения общих представлений данных без необходимости писать слишком много кода.

Были предоставлены аналоги всех старых универсальных представлений, основанных на функциях, а также полностью универсальный базовый класс представлений, который можно использовать в качестве основы для многократно используемых приложений, которые можно легко расширить.

Дополнительную информацию см. в документации по общим представлениям на основе классов. Существует также документ, который поможет вам преобразовать общие представления на основе функций в представления на основе классов <https://raw.githubusercontent.com/django/django/ea9dc9f4b03ae034c1dc080730422dda7a9c2e47/docs/topics/generic-views-migration.txt>`_.

Ведение журнала¶

Django 1.3 adds framework-level support for Python’s logging module. This means you can now easily configure and control logging as part of your Django project. A number of logging handlers and logging calls have been added to Django’s own code as well – most notably, the error emails sent on a HTTP 500 server error are now handled as a logging activity. See the documentation on Django’s logging interface for more details.

Расширенная обработка статических файлов¶

Django 1.3 поставляется с новым дополнительным приложением — django.contrib.staticfiles — которое помогает разработчикам обрабатывать статические медиафайлы (изображения, CSS, JavaScript и т. д.), необходимые для рендеринга полной веб-страницы.

В предыдущих версиях Django было принято размещать статические ресурсы в MEDIA_ROOT вместе с загруженными пользователем файлами и обслуживать их обоих по адресу MEDIA_URL. Одной из целей внедрения приложения staticfiles является упрощение хранения статических файлов отдельно от файлов, загруженных пользователем. Статические ресурсы теперь должны располагаться в подкаталогах static/ ваших приложений или в других каталогах статических ресурсов, перечисленных в STATICFILES_DIRS, и будут обслуживаться по STATIC_URL.

Дополнительную информацию см. в справочной документации приложения или узнайте, как управлять статическими файлами.

поддержка unittest2¶

Python 2.7 introduced some major changes to the unittest library, adding some extremely useful features. To ensure that every Django project can benefit from these new features, Django ships with a copy of unittest2, a copy of the Python 2.7 unittest library, backported for Python 2.4 compatibility.

Для доступа к этой библиотеке Django предоставляет псевдоним модуля django.utils.unittest. Если вы используете Python 2.7 или установили unittest2 локально, Django сопоставит псевдоним с установленной версией библиотеки unittest. В противном случае Django будет использовать собственную версию unittest2.

Чтобы воспользоваться этим псевдонимом, просто используйте:

from django.utils import unittest

везде, где вы исторически использовали:

import unittest

Если вы хотите продолжать использовать базовую библиотеку unittest, вы можете — вы просто не получите ни одной из новых замечательных функций unittest2.

Менеджеры контекста транзакций¶

Пользователи Python 2.5 и выше теперь могут использовать функции управления транзакциями в качестве менеджеров контекста. Например:

with transaction.autocommit():
    # ...

Настраиваемый каскад удаления¶

ForeignKey и OneToOneField теперь принимают аргумент on_delete для настройки поведения при удалении объекта, на который ссылаются. Раньше удаления всегда выполнялись каскадно; доступные альтернативы теперь включают установку нуля, установку по умолчанию, установку любого значения, защиту или ничего не делать.

Для получения дополнительной информации см. документацию on_delete.

Контекстные маркеры и комментарии для переводимых строк.¶

Для строк перевода с неоднозначным значением теперь вы можете использовать функцию pgettext, чтобы указать контекст строки.

А если вы просто хотите добавить некоторую информацию для переводчиков, вы также можете добавить в исходный текст специальные комментарии переводчика.

Для получения дополнительной информации см. Контекстные маркеры и Комментарии для переводчиков.

Улучшения встроенных тегов шаблонов.¶

Во встроенные теги шаблонов Django был внесен ряд улучшений:

• Тег include теперь принимает опцию with, позволяющую указать контекстные переменные для включенного шаблона.

• Тег include теперь принимает опцию only, позволяющую исключить текущий контекст из включенного контекста.

• Тег with теперь позволяет определять несколько переменных контекста в одном блоке with.

• Тег load теперь принимает аргумент from, что позволяет вам загрузить один тег или фильтр из библиотеки.

ШаблонОтвет¶

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

Однако вы не можете (легко) изменить содержимое базового HttpResponse после его создания. Чтобы преодолеть это ограничение, в Django 1.3 добавлен новый класс TemplateResponse. В отличие от базовых объектов HttpResponse, объекты TemplateResponse сохраняют детали шаблона и контекста, которые были предоставлены представлением для вычисления ответа. Окончательный результат ответа не вычисляется до тех пор, пока он не понадобится на более позднем этапе процесса ответа.

Более подробную информацию см. в документации по классу TemplateResponse.

Кэширование изменений¶

В Django 1.3 в инфраструктуру кэширования Django внесено несколько улучшений.

Во-первых, Django теперь поддерживает несколько именованных кешей. Точно так же, как в Django 1.2 появилась поддержка нескольких подключений к базе данных, Django 1.3 позволяет вам использовать новый параметр CACHES для определения нескольких именованных подключений к кэшу.

Во-вторых, в API кэша были добавлены versioning, prefixing и transformation.

В-третьих, создание ключа кэша было обновлено, чтобы учитывать строку запроса запроса в запросах GET.

Наконец, в бэкэнд кэша memcached добавлена ​​поддержка pylibmc.

Более подробную информацию можно найти в документации по кэшированию в Django.

Разрешения для неактивных пользователей¶

Если вы предоставляете собственный бэкэнд аутентификации с параметром support_inactive_user, установленным в значение True, неактивный экземпляр User будет проверять бэкэнд на наличие разрешений. Это полезно для дальнейшей централизации обработки разрешений. Дополнительную информацию см. в документах по аутентификации.

ГеоДжанго¶

Набор тестов GeoDjango теперь включается при запуске набора тестов Django <running-unit-tests> с помощью runtests.py при использовании бэкендов пространственной базы данных.

MEDIA_URL и STATIC_URL должны заканчиваться косой чертой.¶

Раньше для параметра MEDIA_URL требовалась косая черта в конце, только если он содержал суффикс помимо имени домена.

Конечная косая черта теперь обязательна для MEDIA_URL и новой настройки STATIC_URL, если она не пуста. Это гарантирует единообразный способ объединения путей в шаблонах.

Настройки проекта, которые предоставляют любую из обеих настроек без косой черты, теперь будут вызывать сообщение «PendingDeprecationWarning».

В Django 1.4 это же условие вызывает исключение DeprecationWarning, а в Django 1.5 — исключение ImproperlyConfigured.

Все остальное¶

Django 1.1 и 1.2 добавили в Django множество важных элементов, таких как поддержка нескольких баз данных, проверка модели и структура сообщений на основе сеансов. Однако такой акцент на крупных функциях был достигнут за счет множества более мелких функций.

Чтобы компенсировать это, в процессе разработки Django 1.3 основное внимание уделялось добавлению множества небольших, давно существующих запросов на функции. К ним относятся:

• Улучшены инструменты для доступа и управления текущим объектом Site в фреймворке сайтов.

• RequestFactory для имитации запросов в тестах.

• Новое тестовое утверждение — assertNumQueries() — упрощающее тестирование активности базы данных, связанной с представлением.

• Поддержка поиска, охватывающего отношения в list_filter администратора.

• Поддержка файлов cookie HttpOnly.

• mail_admins() и mail_managers() теперь поддерживают легкое прикрепление HTML-контента к сообщениям.

• EmailMessage теперь поддерживает CC.

• Сообщения об ошибках теперь содержат больше подробностей и форматирования страницы ошибок сервера отладки.

• simple_tag() теперь принимает аргумент takes_context, что упрощает написание простых тегов шаблона, требующих доступа к контексту шаблона.

• Новый ярлык render() — альтернатива django.shortcuts.render_to_response(), предоставляющий RequestContext по умолчанию.

• Поддержка объединения выражений F со значениями timedelta при получении или обновлении значений базы данных.

Проверка CSRF теперь применяется к запросам AJAX.¶

До Django 1.2.5 система предотвращения CSRF Django освобождала запросы AJAX от проверки CSRF; однако из-за «проблем безопасности», о которых нам сообщили, все запросы теперь подвергаются проверке CSRF. Обратитесь к документации Django CSRF для получения подробной информации о том, как обрабатывать проверку CSRF в запросах AJAX.

Ограниченные фильтры в интерфейсе администратора¶

До Django 1.2.5 административный интерфейс Django позволял фильтровать любое поле или отношение модели, а не только те, которые указаны в list_filter, посредством манипулирования строкой запроса. Однако из-за проблем с безопасностью, о которых нам сообщили, аргументы поиска строки запроса в администраторе должны относиться к полям или отношениям, указанным в list_filter или date_hierarchy.

Удаление модели не удаляет связанные файлы.¶

В более ранних версиях Django, когда экземпляр модели, содержащий FileField, был удален, FileField взял на себя задачу также удалить файл из внутреннего хранилища. Это открыло путь к нескольким сценариям потери данных, включая откат транзакций и полей в разных моделях, ссылающихся на один и тот же файл. В Django 1.3 при удалении модели метод delete() не вызывается. Если вам нужна очистка потерянных файлов, вам придется сделать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или запланировать периодический запуск, например, через cron).

Поведение рендеринга PasswordInput по умолчанию¶

Виджет формы PasswordInput, предназначенный для использования с полями формы, представляющими пароли, принимает логический аргумент ключевого слова render_value, указывающий, следует ли отправлять его данные обратно в браузер при отображении отправленной формы с ошибками. До Django 1.3 этот аргумент по умолчанию имел значение True, что означает, что отправленный пароль будет отправлен обратно в браузер как часть формы. Разработчики, которые хотели добавить немного дополнительной безопасности, исключив это значение из повторно отображаемой формы, могли создать экземпляр PasswordInput, передав render_value=False .

Однако из-за деликатного характера паролей Django 1.3 выполняет этот шаг автоматически; значение по умолчанию для render_value теперь равно False, и разработчики, которые хотят, чтобы значение пароля возвращалось в браузер при отправке с ошибками (предыдущее поведение), теперь должны явно указать это. Например:

class LoginForm(forms.Form):
    username = forms.CharField(max_length=100)
    password = forms.CharField(widget=forms.PasswordInput(render_value=True))

Очищаемый виджет по умолчанию для FileField¶

Django 1.3 теперь включает виджет формы ClearableFileInput в дополнение к FileInput. ClearableFileInput отображается с флажком для очистки значения поля (если поле имеет значение и не является обязательным); FileInput не предоставил никаких средств для очистки существующего файла от FileField.

ClearableFileInput теперь является виджетом по умолчанию для FileField, поэтому существующие формы, включая FileField, без назначения пользовательского виджета, должны будут учитывать возможный дополнительный флажок в отображаемом выводе формы.

Чтобы вернуться к предыдущему рендерингу (без возможности очистить FileField), используйте виджет FileInput вместо ClearableFileInput. Например, в ModelForm для гипотетической модели Document с FileField с именем document:

from django import forms
from myapp.models import Document

class DocumentForm(forms.ModelForm):
    class Meta:
        model = Document
        widgets = {'document': forms.FileInput}

Новый индекс в таблице сеансов базы данных¶

До Django 1.3 таблица базы данных, используемая серверной частью базы данных для приложения sessions, не имела индекса в столбце expire_date. В результате запросы к таблице сеансов на основе даты (например, запрос, необходимый для очистки старых сеансов) будут выполняться очень медленно, если сеансов будет много.

If you have an existing project that is using the database session backend, you don’t have to do anything to accommodate this change. However, you may get a significant performance boost if you manually add the new index to the session table. The SQL that will add the index can be found by running the sqlindexes admin command:

python manage.py sqlindexes sessions

Больше никаких нецензурных слов¶

Django исторически предоставлял (и соблюдал) список ненормативной лексики. Приложение для комментариев усилило этот список ненормативной лексики, не позволяя людям оставлять комментарии, содержащие одну из этих ненормативной лексики.

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

Если вы хотите восстановить старое поведение, просто поместите параметр PROFANITIES_LIST в свой файл настроек, включающий слова, которые вы хотите запретить (см. commit, который реализовал это изменение, если вы хотите увидеть список слов, которые были исторически запрещены). Однако, если для вас важно избегать ненормативной лексики, вам рекомендуется найти лучший, менее наивный подход к проблеме.

Изменения местного вкуса¶

В Django 1.3 в локальные версии внесены следующие обратно несовместимые изменения:

• Канада (ок.) – Код провинции «Ньюфаундленд и Лабрадор» обновлен на «NL», а не на старый «NF». Кроме того, код провинции Юкон был исправлен на «YT» вместо «YK».

• Индонезия (id) – Провинция «Нанггро-Ачех-Даруссалам (NAD)» была удалена из списка провинций в пользу нового официального названия «Ачех (ACE)».

• Соединенные Штаты Америки (США) – список «штатов», используемый «USStateField», расширился и теперь включает почтовые индексы вооруженных сил. Это обратно несовместимо, если вы полагались на USStateField, не включая их.

Обновления набора форм¶

В Django 1.3 поведение создания FormSet немного изменено. Исторически класс не делал различия между отсутствием передачи данных и передачей пустого словаря. Это не согласовывалось с поведением других частей платформы. Начиная с версии 1.3, если вы передадите пустой словарь, FormSet выдаст ошибку ValidationError.

For example with a FormSet:

>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
>>> ArticleFormSet = formset_factory(ArticleForm)

the following code will raise a ValidationError:

>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']

if you need to instantiate an empty FormSet, don’t pass in the data or use None:

>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)

Вызовы в шаблонах¶

Previously, a callable in a template would only be called automatically as part of the variable resolution process if it was retrieved via attribute lookup. This was an inconsistency that could result in confusing and unhelpful behavior:

>>> Template("{{ user.get_full_name }}").render(Context({'user': user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({'full_name': user.get_full_name}))
u'<bound method User.get_full_name of <...

Эта проблема была решена в Django 1.3 — результатом в обоих случаях будет ``u’Joe Bloggs“`. Хотя предыдущее поведение было бесполезным для языка шаблонов, разработанного для веб-дизайнеров, и никогда намеренно не поддерживалось, возможно, что это изменение может привести к поломке некоторых шаблонов.

Использование собственного SQL для загрузки исходных данных в тестах¶

Django предоставляет специальные перехватчики SQL для внедрения созданного вручную SQL в процесс синхронизации базы данных. Одним из возможных вариантов использования этого пользовательского SQL является вставка данных в вашу базу данных. Если ваш собственный SQL содержит инструкции INSERT, эти вставки будут выполняться каждый раз при синхронизации вашей базы данных. Сюда входит синхронизация любых тестовых баз данных, созданных при запуске набора тестов.

Однако в процессе тестирования Django 1.3 было обнаружено, что эта функция никогда не работала полностью так, как рекламируется. При использовании серверных частей базы данных, которые не поддерживают транзакции, или при использовании TransactionTestCase данные, вставленные с помощью пользовательского SQL, не будут видны в процессе тестирования.

К сожалению, не было возможности исправить эту проблему без введения обратной несовместимости. Вместо того, чтобы оставлять исходные данные, вставленные SQL, в неопределенном состоянии, Django теперь применяет политику, согласно которой данные, вставленные пользовательским SQL, не будут видны во время тестирования.

Это изменение влияет только на процесс тестирования. Вы по-прежнему можете использовать собственный SQL для загрузки данных в рабочую базу данных в рамках процесса syncdb. Если вам необходимо, чтобы данные существовали во время условий тестирования, вам следует либо вставить их с помощью test fixtures, либо использовать метод setUp() вашего тестового примера.

Изменен приоритет загрузки перевода.¶

Была проделана работа по упрощению, рационализации и правильному документированию алгоритма, используемого Django во время выполнения для создания переводов из различных переводов, найденных на диске, а именно:

Для переводимых литералов, найденных в коде и шаблонах Python (домен gettext ``“django“`):

• Изменены приоритеты переводов, включенных в приложения, перечисленные в настройке INSTALLED_APPS. Чтобы обеспечить поведение, совместимое с другими частями Django, которые также используют такие настройки (шаблоны и т. д.), теперь при создании перевода, который будет доступен, приложения, перечисленные первыми, имеют более высокий приоритет, чем те, которые перечислены позже.

• Теперь можно переопределить переводы, поставляемые с приложениями, с помощью параметра LOCALE_PATHS, чьи переводы теперь имеют более высокий приоритет, чем переводы INSTALLED_APPS приложений. Относительный приоритет среди значений, перечисленных в этом параметре, также был изменен, поэтому пути, перечисленные первыми, имеют более высокий приоритет, чем те, которые перечислены позже.

• Подкаталог locale в каталоге, содержащем настройки, который обычно совпадает и известен как каталог проекта, в этом выпуске объявлен устаревшим как источник переводов. (приоритет этих переводов является промежуточным между приложениями и переводами LOCALE_PATHS). См. раздел «Соответствующие устаревшие функции» этого документа.

Для переводимых литералов, найденных в коде JavaScript (домен gettext ``“djangojs“`):

• Аналогично переводу домена 'django': переопределение переводов, поставляемых вместе с приложениями, с помощью параметра LOCALE_PATHS теперь возможно и для этого домена. Эти переводы имеют более высокий приоритет, чем переводы пакетов Python, передаваемые в представление javascript_catalog(). Пути, перечисленные первыми, имеют более высокий приоритет, чем те, которые перечислены позже.

• Переводы в подкаталоге locale каталога проекта никогда не учитывались при переводах JavaScript и остаются в той же ситуации, учитывая прекращение поддержки такого местоположения.

Управление транзакциями¶

При использовании управляемых транзакций, то есть любого режима автофиксации, кроме режима автофиксации по умолчанию, важно, чтобы транзакция была помечена как «грязная». Грязные транзакции фиксируются декоратором commit_on_success или django.middleware.transaction.TransactionMiddleware, а commit_manually заставляет их закрываться явно; чистые транзакции «проходят», что означает, что они обычно откатываются в конце запроса, когда соединение закрывается.

До Django 1.3 транзакции помечались как «грязные» только тогда, когда Django знал о выполненной в них операции изменения; то есть либо была сохранена какая-то модель, либо было выполнено массовое обновление или удаление, либо пользователь явно вызвал transaction.set_dirty(). В Django 1.3 транзакция помечается как грязная при выполнении любой операции с базой данных.

В результате этого изменения вам больше не нужно явно устанавливать транзакцию «грязной», когда вы выполняете необработанный SQL или используете изменяющий данные SELECT. Однако вам действительно необходимо явно закрывать любые транзакции только для чтения, которые управляются с помощью commit_manually(). Например:

@transaction.commit_manually
def my_view(request, name):
    obj = get_object_or_404(MyObject, name__iexact=name)
    return render_to_response('template', {'object':obj})

До Django 1.3 это работало без ошибок. Однако в Django 1.3 это приведет к возникновению ошибки TransactionManagementError, поскольку операция чтения, извлекающая экземпляр MyObject, оставляет транзакцию в грязном состоянии.

Нет сброса пароля для неактивных пользователей¶

До Django 1.3 неактивные пользователи могли запросить электронное письмо для сброса пароля и сбросить свой пароль. В Django 1.3 неактивные пользователи получат то же сообщение, что и несуществующая учетная запись.

Представление сброса пароля теперь принимает from_email¶

Представление django.contrib.auth.views.password_reset() теперь принимает параметр from_email, который передается в метод save() метода password_reset_form в качестве ключевого аргумента. Если вы используете это представление с настраиваемой формой сброса пароля, вам необходимо убедиться, что метод вашей формы save() принимает этот аргумент ключевого слова.

поддержка mod_python¶

Библиотека mod_python не выпускалась с 2007 года и не была зафиксирована с 2008 года. Правление Apache Foundation проголосовало за удаление mod_python из набора активных проектов в репозиториях контроля версий, а ее ведущий разработчик сосредоточил все свои усилия на более легком, тонком, более стабильном и гибком бэкенде mod_wsgi.

Если вы в настоящее время используете обработчик запросов mod_python, вам следует повторно развернуть свои проекты Django, используя другой обработчик запросов. mod_wsgi — это обработчик запросов, рекомендованный проектом Django, но также поддерживается FastCGI. Поддержка развертывания mod_python будет удалена в Django 1.5.

Универсальные представления на основе функций¶

В результате введения универсальных представлений на основе классов универсальные представления на основе функций, предоставляемые Django, стали устаревшими. Следующие модули и содержащиеся в них представления устарели:

• django.views.generic.create_update

• django.views.generic.date_based

• django.views.generic.list_detail

• django.views.generic.simple

Атрибут шаблона ответа тестового клиента¶

тестовый клиент Django возвращает Response объекты, аннотированные дополнительной информацией о тестировании. В версиях Django до 1.3 сюда входил атрибут template, содержащий информацию о шаблонах, отображаемых при генерации ответа: либо None, либо один объект Template, либо список объектов Template. Эта несогласованность возвращаемых значений (иногда список, иногда нет) затрудняла работу с атрибутом.

В Django 1.3 атрибут template устарел в пользу нового атрибута templates, который всегда представляет собой список, даже если он имеет только один элемент или не содержит элементов.

DjangoTestRunner¶

В результате введения поддержки unittest2 функции django.test.simple.DjangoTestRunner (включая отказоустойчивость и завершение теста Ctrl-C) стали излишними. Ввиду этой избыточности DjangoTestRunner был превращен в пустой класс-заполнитель и будет полностью удален в Django 1.5.

Изменения в url и ssi¶

Most template tags will allow you to pass in either constants or variables as arguments – for example:

{% extends "base.html" %}

allows you to specify a base template as a constant, but if you have a context variable templ that contains the value base.html:

{% extends templ %}

также является законным.

Однако по историческим причинам URL и ssi различаются. Эти теги используют второй синтаксис, без кавычек, но интерпретируют аргумент как константу. Это означает, что невозможно использовать контекстную переменную в качестве цели тега url и ssi.

Django 1.3 marks the start of the process to correct this historical accident. Django 1.3 adds a new template library – future – that provides alternate implementations of the url and ssi template tags. This future library implement behavior that makes the handling of the first argument consistent with the handling of all other variables. So, an existing template that contains:

{% url sample %}

should be replaced with:

{% load url from future %}
{% url 'sample' %}

Теги, реализующие старое поведение, устарели, и в Django 1.5 старое поведение будет заменено новым. Чтобы обеспечить совместимость с будущими версиями Django, существующие шаблоны должны быть изменены для использования новых «будущих» библиотек и синтаксиса.

Изменения в способах входа администратора¶

В предыдущей версии приложение администратора определяло методы входа в несколько мест и игнорировало почти идентичную реализацию в уже используемом приложении аутентификации. Побочным эффектом этого дублирования стало отсутствие принятия изменений, внесенных в r12634 для поддержки более широкого набора символов для имен пользователей.

В этом выпуске происходит рефакторинг механизма входа администратора для использования подкласса AuthenticationForm вместо ручной проверки формы. Ранее недокументированный метод django.contrib.admin.sites.AdminSite.display_login_form был удален в пользу нового атрибута login_form.

Команды управления reset и sqlreset¶

Эти команды устарели. Команды «flush» и «sqlflush» можно использовать для удаления всего. Вы также можете использовать операторы ALTER TABLE или DROP TABLE вручную.

ГеоДжанго¶

• Основанная на функции настройка:TEST_RUNNER, ранее использовавшаяся для выполнения набора тестов GeoDjango, django.contrib.gis.tests.run_gis_tests, была признана устаревшей для средства запуска на основе классов django.contrib.gis.tests.GeoDjangoTestSuiteRunner.

• Раньше вызов transform() ничего не делал, когда GDAL был недоступен. Теперь правильно генерируется исключение GEOSException, указывающее на возможный ошибочный код приложения. Предупреждение теперь выдается, если transform() вызывается, когда SRID геометрии меньше 0 или Нет.

CZBirthNumberField.clean¶

Ранее метод clean() этого поля принимал второй аргумент, гендерный, который позволял выполнять более строгие проверки, однако, поскольку этот аргумент фактически никогда не мог быть передан из механизма формы Django, теперь он ожидает прекращения поддержки.

CompatCookie¶

Ранее django.http предоставлял недокументированный класс CompatCookie, который представлял собой оболочку для исправления ошибок стандартной библиотеки SimpleCookie. Поскольку исправления распространяются вверх по течению, это теперь устарело - вместо этого вам следует использовать from django.http import SimpleCookie.

Загрузка переводов на уровне проекта¶

В этом выпуске Django начинается процесс прекращения поддержки для включения переводов, расположенных в так называемом пути проекта, в процесс построения перевода, выполняемый во время выполнения. Параметр LOCALE_PATHS можно использовать для той же задачи, добавив путь файловой системы к каталогу locale, содержащему переводы на уровне проекта, к значению этого параметра.

Обоснование такого решения:

• Путь к проекту всегда был слабо определенной концепцией (на самом деле каталог, используемый для поиска переводов на уровне проекта, — это каталог, содержащий модуль настроек), и в других частях платформы произошел сдвиг, чтобы прекратить использовать его в качестве ссылки для расположения ресурсов во время выполнения.

• Обнаружение подкаталога locale имеет тенденцию к сбою, если сценарий развертывания более сложен, чем базовый. например это не удается, если модуль настроек является каталогом (тикет № 10765).

• There are potential strange development- and deployment-time problems like the fact that the project_dir/locale/ subdir can generate spurious error messages when the project directory is added to the Python path (manage.py runserver does this) and then it clashes with the equally named standard library module, this is a typical warning message:

  /usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
  import locale, copy, os, re, struct, sys
  

• Это расположение не было включено в процесс создания перевода для литералов JavaScript. Это прекращение поддержки устраняет такое несоответствие.

PermWrapper перемещен в django.contrib.auth.context_processors¶

В Django 1.2 мы начали процесс изменения местоположения процессора контекста auth с django.core.context_processors на django.contrib.auth.context_processors. Однако класс поддержки PermWrapper был по ошибке исключен из этой миграции. В Django 1.3 класс PermWrapper также был перенесен в django.contrib.auth.context_processors вместе с классом поддержки PermLookupDict. Новые классы функционально идентичны своим старым версиям; изменилось только расположение модуля.

Удаление XMLField¶

Когда Django был впервые выпущен, Django включал в себя XMLField, который выполнял автоматическую проверку XML для любого ввода поля. Однако эта функция проверки не выполнялась с момента появления новых форм до версии 1.0. В результате XMLField в его текущей реализации функционально неотличим от простого TextField.

По этой причине в Django 1.3 ускорилось прекращение поддержки XMLField — вместо прекращения поддержки двух выпусков XMLField будет полностью удален в Django 1.4.

Код легко обновить, чтобы учесть это изменение — просто замените все случаи использования XMLField на TextField и удалите аргумент ключевого слова Schema_path (если он указан).