Примечания к выпуску Django 1.3

23 марта 2011 г.

Добро пожаловать в Django 1.3!

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

Обзор

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

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

Совместимость с Python

Выпуск Django 1.2 был отмечен первым сдвигом в политике совместимости Django с Python; до Django 1.2 Django поддерживал любую версию Python 2.x, начиная с 2.3. Начиная с Django 1.2, минимальные требования были повышены до Python 2.4.

Django 1.3 продолжает поддерживать Python 2.4, но станет последним выпуском Django, в котором это будет реализовано; начиная с Django 1.4, минимальная поддерживаемая версия Python будет 2.5. Вскоре после выпуска Django 1.3 будет опубликован документ с изложением наших полных сроков прекращения поддержки Python 2.x и перехода на Python 3.x.

Что нового в Django 1.3

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

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

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

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

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

Django 1.3 добавляет поддержку logging модуля Python на уровне фреймворка . Это означает, что теперь вы можете легко настраивать и контролировать ведение журнала как часть вашего проекта Django. В собственный код Django был добавлен ряд обработчиков журналов и вызовов журналирования - в первую очередь, сообщения об ошибках, отправляемые при ошибке сервера HTTP 500, теперь обрабатываются как действия журналирования. Дополнительную информацию см. В документации по интерфейсу ведения журнала Django .

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

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

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

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

unittest2поддержка

Python 2.7 внес некоторые важные изменения в unittestбиблиотеку, добавив несколько чрезвычайно полезных функций. Чтобы гарантировать, что каждый проект Django может извлечь выгоду из этих новых функций, Django поставляется с копией unittest2 , копией unittestбиблиотеки Python 2.7 , перенесенной для совместимости с Python 2.4.

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

TemplateResponse

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

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

Подробнее см. Документацию по TemplateResponseклассу.

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

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

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

Во- вторых, управление версиями , на веб-узле префиксов и преобразования , которые были добавлены в API кэша.

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

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

Подробнее см. Документацию по кешированию в Django .

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

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

GeoDjango

Набор тестов GeoDjango теперь включен при запуске набора тестов Django с runtests.py использованием бэкэндов пространственной базы данных .

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

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

Теперь для новой настройки требуется завершающая косая черта, если она не пуста. Это гарантирует, что существует единообразный способ комбинирования путей в шаблонах.MEDIA_URLSTATIC_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 expressionstimedelta

Обратно-несовместимые изменения в 1.3

Проверка 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, когда экземпляр модели, содержащий a, FileFieldбыл удален, FileFieldон также удалял файл из внутреннего хранилища. Это открыло дверь для нескольких сценариев потери данных, включая откат транзакций и полей в разных моделях, ссылающихся на один и тот же файл. В Django 1.3, когда модель будет удалена в FileField«S delete()метод не будет вызван. Если вам нужно очистить потерянные файлы, вам нужно будет обработать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или по расписанию, чтобы запускать периодически, например, cron).

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

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

Однако из-за секретности паролей Django 1.3 выполняет этот шаг автоматически; значение по умолчанию render_value- now 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теперь является виджетом по умолчанию для a 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 таблица базы данных, используемая серверной частью базы данных для приложения сеансов , не имела индекса в expire_dateстолбце. В результате запросы к таблице сеансов на основе даты, такие как запрос, необходимый для очистки старых сеансов, были бы очень медленными, если бы сеансов было много.

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

python manage.py sqlindexes sessions

Больше никаких непристойных слов

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

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

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

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

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

  • Канада (ca) - Код провинции «Ньюфаундленд и Лабрадор» был изменен на «NL», а не на более старый «NF». Кроме того, код провинции территории Юкон был изменен на «YT» вместо «YK».
  • Индонезия (id) - Провинция «Нанггро Ачех Даруссалам (НАД)» была удалена из списка провинций в пользу нового официального названия «Ачех (ACE)».
  • Соединенные Штаты Америки (США) - список «штатов», используемых в США, USStateFieldбыл расширен за счет включения почтовых индексов вооруженных сил. Это обратно несовместимо, если вы рассчитывали USStateFieldне включать их.

Обновления FormSet

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

Например, с FormSet:

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

следующий код вызовет ValidationError:

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

если вам нужно создать пустой экземпляр FormSet, не передавайте данные и не используйте None:

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

Вызываемые в шаблонах

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

>>> 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 процесса. Если вам требуется, чтобы данные существовали в условиях тестирования, вы должны либо вставить их с помощью тестовых приспособлений , либо использовать setUp()метод вашего тестового примера.

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

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

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

  • Изменены приоритеты переводов, включенных в приложения, перечисленные в INSTALLED_APPSнастройках. Чтобы обеспечить поведение, совместимое с другими частями Django, которые теперь также используют такие настройки (шаблоны и т. Д.), При создании перевода, который будет доступен, приложения, перечисленные первыми, имеют более высокий приоритет, чем перечисленные позже.
  • Теперь можно переопределить переводы, поставляемые с приложениями, с помощью LOCALE_PATHSпараметра, переводы которого имеют более высокий приоритет, чем переводы INSTALLED_APPSприложений. Относительный приоритет среди значений, перечисленных в этом параметре, также был изменен, поэтому пути, указанные первыми, имеют более высокий приоритет, чем пути, перечисленные позже.
  • localeПодкаталог каталога , содержащего параметры, которые обычно совпадает с и известен как каталог проекта является устаревшим в этом выпуске в качестве источника переводов. (приоритет этих переводов является промежуточным между заявками и LOCALE_PATHS переводами). См. Соответствующий раздел этого документа по устаревшим функциям .

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

  • Аналогично '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 это вызовет a, TransactionManagementErrorпотому что операция чтения, которая извлекает MyObjectэкземпляр, оставляет транзакцию в грязном состоянии.

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

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

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

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

Функции, устаревшие в версии 1.3

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

Код, использующий любую из перечисленных ниже функций, вызовет PendingDeprecationWarningв Django 1.3. По умолчанию это предупреждение будет беззвучным, но его можно включить с помощью warnings модуля Python или путем запуска Python с флагом -Wdили -Wall.

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

Смотрите также

Для получения дополнительных сведений см. Документацию по процессу выпуска Django и сроки прекращения поддержки .

mod_pythonподдержка

mod_pythonБиблиотека не имела выпуск с 2007 года или фиксации с 2008 года плата Фонд Apache проголосовал за исключение 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

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

Тестовый клиент 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

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

{% extends "base.html" %}

позволяет указать базовый шаблон как константу, но если у вас есть переменная контекста templ, содержащая значение base.html:

{% extends templ %}

также законно.

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

Django 1.3 знаменует начало процесса исправления этой исторической аварии. Django 1.3 добавляет новую библиотеку шаблонов - future- которая предоставляет альтернативные реализации тегов шаблонов urlи ssi. Эта futureбиблиотека реализует поведение, которое согласовывает обработку первого аргумента с обработкой всех других переменных. Итак, существующий шаблон, содержащий:

{% url sample %}

следует заменить на:

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

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

Изменения в способах входа в админку

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

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

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

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

GeoDjango

  • Функции на основе TEST_RUNNERранее использовались для выполнения набора тестов GeoDjango, django.contrib.gis.tests.run_gis_testsбыла устаревшим для бегуна на основе классов, django.contrib.gis.tests.GeoDjangoTestSuiteRunner.
  • Раньше, transform()когда GDAL был недоступен , при вызове незаметно ничего не происходило. Теперь GEOSExceptionправильно поднят, чтобы указать на возможный ошибочный код приложения. Теперь transform()появляется предупреждение, если оно вызывается, когда SRID геометрии меньше 0 или None.

CZBirthNumberField.clean

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

CompatCookie

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

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

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

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

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

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

  • Существуют потенциальные странные проблемы во время разработки и развертывания, такие как тот факт, что project_dir/locale/подкаталог может генерировать ложные сообщения об ошибках, когда каталог проекта добавляется в путь Python ( делает это), а затем он конфликтует с одноименным стандартным библиотечным модулем, это типичное предупреждающее сообщение:manage.py runserver

    /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 для любого ввода поля. Однако эта функция проверки не выполнялась с момента появления newformsдо версии 1.0. В результате XMLFieldреализованный в настоящее время функционально неотличим от простого TextField.

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

Это легко обновить код для размещения этого изменения - просто замените все использования XMLFieldс TextField, и удалить schema_pathаргумент ключевого слова (если он указан).

Copyright ©2021 All rights reserved