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

Поддержка нескольких баз данных ¶

Django 1.2 добавляет возможность использовать более одной базы данных в вашем проекте Django. Запросы могут быть выполнены в конкретной базе данных с помощью using()метода QuerySetобъектов. Отдельные объекты могут быть сохранены в конкретной базе данных, указав using аргумент при вызове save().

Проверка модели ¶

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

Улучшенная защита CSRF ¶

Django теперь имеет значительно улучшенную защиту от атак с подделкой межсайтовых запросов (CSRF) . Этот тип атаки происходит, когда вредоносный веб-сайт содержит ссылку, кнопку формы или некоторый код JavaScript, который предназначен для выполнения определенных действий на вашем веб-сайте с использованием учетных данных вошедшего в систему пользователя, который посещает вредоносный сайт в своем браузере. Также рассматривается родственный тип атаки, «CSRF входа в систему», когда атакующий сайт обманом заставляет браузер пользователя войти на сайт с чужими учетными данными.

Фреймворк сообщений ¶

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

Разрешения на уровне объекта ¶

Добавлена ​​основа для указания разрешений на уровне отдельных объектов. Хотя в ядре реализации этого нет, пользовательский сервер аутентификации может предоставить эту реализацию, и она будет использоваться django.contrib.auth.models.User. Дополнительную информацию см. В документации по аутентификации .

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

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

Мягкие требования к именам пользователей ¶

Встроенный в Userмодели usernameполя теперь позволяет более широкий диапазон символов, в том числе @, +, .и -персонажей.

Бэкэнды электронной почты ¶

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

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

«Умный» ifтег ¶

ifТег был обновлен , чтобы быть гораздо более мощным. Во-первых, мы добавили поддержку операторов сравнения. Вам больше не нужно будет вводить:

{% ifnotequal a b %}
 ...
{% endifnotequal %}

Теперь вы можете сделать это:

{% if a != b %}
 ...
{% endif %}

На самом деле нет причин использовать или больше, если только вы не ностальгический тип.{% ifequal %}{% ifnotequal %}

Операторы Поддерживаются ==, !=, <, >, <=, >=, inи , все из которых работают как операторы Python, в дополнение к , и , которые уже были поддержаны.not inandornot

Кроме того, теперь в ifвыражении можно использовать фильтры . Например:

<div
  {% if user.email|lower == message.recipient|lower %}
    class="highlight"
  {% endif %}
>{{ message }}</div>

Кеширование шаблонов ¶

В предыдущих версиях Django каждый раз, когда вы отображали шаблон, он перезагружался с диска. В Django 1.2 вы можете использовать кэшированный загрузчик шаблонов для однократной загрузки шаблонов, а затем кэшировать результат для каждого последующего рендеринга. Это может привести к значительному повышению производительности, если ваши шаблоны разбиты на множество более мелких подшаблонов (с помощью тегов или ).{% extends %}{% include %}

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

Загрузчики шаблонов на основе классов ¶

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

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

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

Натуральные ключи в светильниках ¶

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

Быстрый отказ для тестов ¶

И testподкоманда, django-admin.pyи runtests.pyсценарий, используемые для запуска собственного набора тестов Django, теперь поддерживают эту --failfastопцию. Если этот параметр указан, то после сбоя средство выполнения тестов завершает работу вместо продолжения выполнения теста. Кроме того, обработка Ctrl-Cво время тестового запуска была улучшена, чтобы запустить плавный выход из тестового запуска, который сообщает подробную информацию о тестах, которые были запущены до прерывания.

BigIntegerField¶

Модели теперь могут использовать 64-битный BigIntegerFieldтип.

Улучшенная локализация ¶

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

readonly_fieldsв ModelAdmin¶

django.contrib.admin.ModelAdmin.readonly_fieldsбыл добавлен для включения нередактируемых полей на страницах добавления / изменения для моделей и инлайнов. Поля и вычисляемые значения могут отображаться рядом с редактируемыми полями.

Настраиваемая подсветка синтаксиса ¶

Теперь вы можете использовать DJANGO_COLORSпеременная среды для изменения или отключения цветов, используемых django-admin.pyдля выделения синтаксиса .

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

Каналы синдикации теперь могут использоваться непосредственно как представления в вашем URLconf . Это означает, что вы можете полностью контролировать структуру URL-адресов ваших каналов. Как и любое другое представление, представления каналов передаютсяrequestобъекту, поэтому вы можете делать все, что обычно делаете с представлением, например, управление доступом на основе пользователя или создание канала с именованным URL-адресом.

GeoDjango ¶

Наиболее важной новой функцией GeoDjango в версии 1.2 является поддержка нескольких пространственных баз данных. В результате теперь включены следующие серверные части пространственной базы данных :

• django.contrib.gis.db.backends.postgis
• django.contrib.gis.db.backends.mysql
• django.contrib.gis.db.backends.oracle
• django.contrib.gis.db.backends.spatialite

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

Была добавлена ​​поддержка полей 3D-геометрии, которую можно включить, задав для dim ключевого слова 3 в вашем файле GeometryField. Extent3DСовокупности и extent3d() GeoQuerySetметоды были добавлены как часть этой функции.

В force_rhr(), reverse_geom()и geohash() GeoQuerySet методы являются новыми.

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

Интерфейс GDAL теперь позволяет пользователю устанавливать для spatial_filterфункций, возвращаемых при итерации по Layer.

Наконец, документация GeoDjango теперь включена в состав Django и больше не размещается отдельно на geodjango.org .

Обработка встроенных связанных объектов с помощью JavaScript в админке ¶

Если в браузере пользователя включен JavaScript, интерфейс для встроенных объектов в админке теперь позволяет динамически добавлять и удалять встроенные объекты. Пользователи без браузеров с поддержкой JavaScript не увидят изменений в поведении встроенных объектов.

Новые nowсимволы описателя формата тега шаблона: cи u¶

Аргумент для nowполучил два новых символа формата: cчтобы указать, что значение datetime должно быть отформатировано в формате ISO 8601, uчто позволяет выводить микросекундную часть значения datetime или времени.

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

Защита от CSRF ¶

Мы внесли большие изменения в способ работы защиты CSRF, подробно описанные в документации CSRF . Вот основные изменения, о которых вам следует знать:

• CsrfResponseMiddlewareи CsrfMiddlewareустарели и будут полностью удалены в Django 1.4 в пользу тега шаблона, который следует вставлять в формы.

• Все приложения contrib используют csrf_protectдекоратор для защиты просмотра. Это требует использования csrf_tokenтега шаблона в шаблоне. Если вы использовали пользовательские шаблоны для представлений contrib, вы ДОЛЖНЫ ПРОЧИТАТЬ ИНСТРУКЦИИ ПО ОБНОВЛЕНИЮ, чтобы исправить эти шаблоны.

  Документация удалена

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

• CsrfViewMiddlewareвключен MIDDLEWARE_CLASSESпо умолчанию. Это включает защиту CSRF по умолчанию, поэтому представления, которые принимают запросы POST, должны быть написаны для работы с промежуточным программным обеспечением. Инструкции о том, как это сделать, можно найти в документации CSRF.

• Весь CSRF перемещен из contrib в ядро ​​(с обратно совместимым импортом в старых местах, которые устарели и перестанут поддерживаться в Django 1.4).

get_db_prep_*()методы на Field¶

До Django 1.2 пользователь Fieldимел возможность определять несколько функций для поддержки преобразования значений Python в значения, совместимые с базой данных. Настраиваемое поле может выглядеть примерно так:

class CustomModelField(models.Field):
    # ...
    def db_type(self):
        # ...

    def get_db_prep_save(self, value):
        # ...

    def get_db_prep_value(self, value):
        # ...

    def get_db_prep_lookup(self, lookup_type, value):
        # ...

В версии 1.2 эти три метода претерпели изменения в прототипе, и были введены два дополнительных метода:

class CustomModelField(models.Field):
    # ...

    def db_type(self, connection):
        # ...

    def get_prep_value(self, value):
        # ...

    def get_prep_lookup(self, lookup_type, value):
        # ...

    def get_db_prep_save(self, value, connection):
        # ...

    def get_db_prep_value(self, value, connection, prepared=False):
        # ...

    def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
        # ...

Эти изменения необходимы для поддержки нескольких баз данных - db_typeи get_db_prep_*больше не могут делать никаких предположений относительно базы данных, для которой они готовятся. Теперь connection аргумент предоставляет методам подготовки конкретное соединение, для которого готовится значение.

Существуют два новых метода, позволяющих отличать общие требования к подготовке данных от требований, специфичных для базы данных. preparedАргумент используется для указания метода подготовки базы данных , была ли выполнена общая подготовка значения. Если prepared=Falseдля get_db_prep_*()вызовов предоставляется неподготовленное (т. Е. ) Значение , они должны вызывать соответствующие get_prep_*()вызовы для выполнения общей подготовки данных.

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

Если в ваших get_db_prep_*()методах не использовалось соединение с базой данных, вы сможете выполнить обновление, переименовав get_db_prep_value()в get_prep_value()и get_db_prep_lookup()в get_prep_lookup(). Если вам требуются преобразования, специфичные для базы данных, вам нужно будет предоставить реализацию, get_db_prep_*которая использует connection аргумент для разрешения значений, специфичных для базы данных.

Теги шаблонов с отслеживанием состояния ¶

Теги шаблонов, которые хранят состояние рендеринга в своем Nodeподклассе, всегда были уязвимы для обеспечения безопасности потоков и других проблем; Однако, начиная с Django 1.2, они также могут вызывать проблемы при использовании с новым кешированным загрузчиком шаблонов .

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

Вам также может потребоваться обновить свои шаблоны, если вы полагались на то, что реализация тегов шаблонов Django не является потокобезопасной. cycleТег является , скорее всего , будут затронуты таким образом, особенно при использовании в сочетании с includeтегом. Рассмотрим следующий фрагмент шаблона:

{% for object in object_list %}
    {% include "subtemplate.html" %}
{% endfor %}

с subtemplate.htmlнадписью:

{% cycle 'even' 'odd' %}

Используя небезопасный от потоков, рендерер до Django 1.2, это выведет:

even odd even odd ...

Используя потокобезопасный рендерер Django 1.2, вместо этого вы получите:

even even even even ...

Это потому, что каждый рендеринг includeтега является независимым. Когда cycleтег не был потокобезопасным, состояние cycleтега могло просочиться между несколькими отрисовками одного и того же include. Теперь, когда cycleтег является потокобезопасным, эта утечка больше не происходит.

user_passes_test, login_requiredи permission_required¶

django.contrib.auth.decoratorsпредоставляет декораторов login_required, permission_requiredи user_passes_test. Раньше можно было использовать эти декораторы как в функциях (где первый аргумент - это «запрос»), так и в методах (где первый аргумент - «сам», а второй аргумент - «запрос»). К сожалению, в поддерживающем это коде были обнаружены недостатки: он работает только в ограниченных обстоятельствах и вызывает ошибки, которые очень трудно отладить, когда он не работает.

По этой причине поведение «автоадаптация» было удалено, и если вы используете эти декораторы в методах, вам нужно будет вручную применить, django.utils.decorators.method_decorator()чтобы преобразовать декоратор в тот, который работает с методами. Например, вы бы изменили код следующим образом:

class MyClass(object):

    @login_required
    def my_view(self, request):
        pass

к этому:

from django.utils.decorators import method_decorator

class MyClass(object):

    @method_decorator(login_required)
    def my_view(self, request):
        pass

или же:

from django.utils.decorators import method_decorator

login_required_m = method_decorator(login_required)

class MyClass(object):

    @login_required_m
    def my_view(self, request):
        pass

Для тех из вас, кто следил за основной веткой разработки, это изменение также относится к другим декораторам, представленным с версии 1.1, включая все csrf_protect, cache_controlчто создано с использованием decorator_from_middleware.

ifизменения тегов ¶

Из-за новых функций в ifтеге шаблона он больше не принимает "and", "или" и "not" как допустимые имена переменных . Раньше эти строки можно было использовать как имена переменных. Теперь статус ключевого слова всегда применяется, а код шаблона, такой как или, будет выдавать . Кроме того, это новое ключевое слово и, следовательно, недопустимое имя переменной в этом теге.{% if not %}{% if and %}TemplateSyntaxErrorin

LazyObject¶

LazyObject - это недокументированный, но часто используемый служебный класс, используемый для ленивой упаковки других объектов неизвестного типа.

В Django 1.1 и ранее он обрабатывал интроспекцию нестандартным способом, в зависимости от обернутых объектов, реализующих общедоступный метод с именем get_all_members(). Поскольку это могло легко привести к конфликту имен, он был изменен для использования стандартного метода интроспекции Python, включающего __members__и __dir__().

Если вы использовали LazyObjectсвой собственный код и реализовали get_all_members()метод для обернутых объектов, вам необходимо внести несколько изменений:

Во-первых, если у вашего класса нет особых требований к интроспекции (т. Е. Вы не реализовали __getattr__()или другие методы, которые допускают атрибуты, не обнаруживаемые обычными механизмами), вы можете просто удалить get_all_members()метод. Реализация по умолчанию LazyObjectсделает все правильно.

Если у вас более сложные требования к интроспекции, сначала переименуйте get_all_members()метод в __dir__(). Это стандартный метод самоанализа для Python 2.6 и выше. Если вам требуется поддержка версий Python ранее, чем 2.6, добавьте в класс следующий код:

__members__ = property(lambda self: self.__dir__())

__dict__на экземплярах модели ¶

Исторически __dict__атрибут экземпляра модели содержал только атрибуты, соответствующие полям модели.

Чтобы поддерживать несколько конфигураций базы данных, Django 1.2 добавил _stateатрибут к экземплярам объектов. Этот атрибут появится __dict__для экземпляра модели. Если ваш код использует итерацию __dict__для получения списка полей, вы должны быть готовы обработать или отфильтровать _stateатрибут.

Код состояния выхода из программы Test Runner ¶

Код статуса выхода тестовых исполнителей ( tests/runtests.pyи ) больше не представляет количество неудачных тестов, потому что сбой 256 или более тестов привел к неправильному коду статуса выхода. Код статуса выхода для средства выполнения тестов теперь равен 0 в случае успеха (отсутствие неудачных тестов) и 1 для любого количества неудачных тестов. При необходимости количество неудачных тестов можно найти в конце вывода средства выполнения тестов.python manage.py test

Кодировка файлов cookie ¶

Чтобы исправить ошибки с файлами cookie в Internet Explorer, Safari и, возможно, других браузерах, наша кодировка значений файлов cookie была изменена таким образом, что запятая и точка с запятой обрабатываются как небезопасные символы и, следовательно, кодируются как \054и \073соответственно. Это может привести к обратной несовместимости, особенно если вы храните запятую или точку с запятой в файлах cookie и используете код JavaScript, который анализирует значения файлов cookie и управляет ими на стороне клиента.

ModelForm.is_valid()и ModelForm.errors¶

Большая часть работы по проверке ModelForms перенесена на уровень модели. В результате при первом вызове ModelForm.is_valid(), доступе ModelForm.errorsили ином запуске проверки формы ваша модель будет очищена на месте. Раньше это преобразование происходило при сохранении модели. Если вам нужен неизмененный экземпляр вашей модели, вы должны передать копию ModelFormконструктору.

BooleanFieldв MySQL ¶

В предыдущих версиях Django модель BooleanFieldпод MySQL возвращала свое значение как 1или 0, вместо True или False; для большинства людей это не было проблемой, потому что bool это подкласс intPython. Однако в Django 1.2 BooleanFieldMySQL правильно возвращает реальный bool. Единственный раз, когда это когда-либо должно быть проблемой, - это если вы ожидали, что repra BooleanFieldбудет печатать 1или 0.

Изменения в интерпретации max_numв FormSets ¶

В рамках улучшений, внесенных в обработку наборов форм, значение по умолчанию и интерпретация max_numпараметра для функций django.forms.formsets.formset_factory () и django.forms.models.modelformset_factory () немного изменились. Это изменение также влияет на способ использования max_numаргумента для встроенных административных объектов.

Ранее значение по умолчанию для max_numбыло 0(ноль). FormSets затем использовал логическое значение, max_numчтобы определить, должно ли быть наложено ограничение на количество сгенерированных форм. Значение по умолчанию 0означает, что не существует ограничения по умолчанию на количество форм в FormSet.

Начиная с 1.2, значение по умолчанию для max_numбыло изменено на None, и FormSets будет различать значение Noneи значение 0. Значение Noneуказывает на отсутствие ограничений на количество форм; значение 0 указывает, что должно быть введено не более 0 форм. Это не обязательно означает, что никакие формы не будут отображаться - подробности см. В документации ModelFormSet .

Если вы вручную указывали значение 0for max_num, вам нужно будет обновить определения FormSet и / или admin.

email_re¶

Недокументированное регулярное выражение для проверки адресов электронной почты было перемещено из django.form.fieldsв django.core.validators. Вам нужно будет обновить свой импорт, если вы его используете.

Указание баз данных ¶

До Django 1.2 Django использовал ряд настроек для управления доступом к одной базе данных. Django 1.2 представляет поддержку нескольких баз данных, и в результате изменился способ определения параметров базы данных.

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

В старом формате (до 1.2) у вас был ряд DATABASE_ настроек в вашем файле настроек. Например:

DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'

Эти настройки теперь находятся в словаре с именем DATABASES. Каждый элемент в словаре соответствует одному соединению с базой данных, имя которого 'default'описывает соединение с базой данных по умолчанию. Имена настроек также были сокращены. Настройки предыдущего примера теперь будут выглядеть так:

DATABASES = {
    'default': {
        'NAME': 'test_db',
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'USER': 'myusername',
        'PASSWORD': 's3krit',
    }
}

Это влияет на следующие настройки:

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

В дополнение к изменению структуры, Django 1.2 убирает специальную обработку для встроенных баз данных. Все серверные части базы данных теперь должны указываться полностью определенным именем модуля (т. Е. django.db.backends.postgresql_psycopg2, А не просто postgresql_psycopg2).

postgresqlсерверная часть базы данных ¶

psycopg1Библиотека не была обновлена с октября 2005 г. В результате, postgresqlбаза данных серверной, которая использует эту библиотеку, является устаревшим.

Если вы в настоящее время используете postgresqlсерверную часть, вам следует перейти на ее использование postgresql_psycopg2. Чтобы обновить свой код, установите psycopg2библиотеку и измените ENGINEнастройку для использования django.db.backends.postgresql_psycopg2.

Промежуточное ПО для перезаписи ответов CSRF ¶

CsrfResponseMiddleware, промежуточное ПО, которое автоматически вставляло токены CSRF в POSTформы на исходящих страницах, устарело в пользу метода шаблонных тегов (см. выше) и будет полностью удалено в Django 1.4. CsrfMiddleware, который включает в себя функции CsrfResponseMiddlewareи CsrfViewMiddleware, также устарел.

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

SMTPConnection¶

Этот SMTPConnectionкласс устарел и заменен универсальным серверным API электронной почты. Старый код, который явно создавал экземпляр SMTPConnection:

from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

… Теперь должен вызывать get_connection()для создания экземпляра общего почтового соединения:

from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

В зависимости от значения EMAIL_BACKENDпараметра это может не возвращать SMTP-соединение. Если вам явно требуется SMTP-соединение для отправки электронной почты, вы можете явно запросить SMTP-соединение:

from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)

Если ваш вызов для создания экземпляра SMTPConnectionтребуемых дополнительных аргументов, эти аргументы могут быть переданы get_connection()вызову:

connection = get_connection('django.core.mail.backends.smtp.EmailBackend', hostname='localhost', port=1234)

API пользовательских сообщений ¶

API для хранения сообщений в пользовательской Messageмодели (через user.message_set.create) теперь устарел и будет удален в Django 1.4 в соответствии со стандартным процессом выпуска .

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

user.message_set.create('a message')

… Со следующим:

from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')

Кроме того, если вы воспользуетесь этим методом, вам необходимо заменить следующее:

for message in user.get_and_delete_messages():
    ...

…с участием:

from django.contrib import messages
for message in messages.get_messages(request):
    ...

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

Вспомогательные функции формата даты ¶

django.utils.translation.get_date_formats()и django.utils.translation.get_partial_date_formats()были объявлены устаревшими в пользу соответствующих вызовов django.utils.formats.get_format(), которые учитывают языковые стандарты, когда USE_L10Nустановлено значение True, и возвращается к настройкам по умолчанию, если установлено значение False.

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

from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()

…использовать:

from django.utils import formats
date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')

Или при прямом форматировании значения даты:

from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')

То же самое относится к глобальным переменным, находящимся в django.forms.fields:

• DEFAULT_DATE_INPUT_FORMATS
• DEFAULT_TIME_INPUT_FORMATS
• DEFAULT_DATETIME_INPUT_FORMATS

Используйте, django.utils.formats.get_format()чтобы получить подходящие форматы.

Функциональные средства запуска тестов ¶

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

Feedв django.contrib.syndication.feeds¶

django.contrib.syndication.feeds.FeedКласс был заменен django.contrib.syndication.views.Feedклассом. Старый feeds.Feedкласс устарел и будет удален в Django 1.4.

Новый класс имеет почти идентичный API, но позволяет использовать экземпляры в качестве представлений. Например, рассмотрим использование старой структуры в следующем URLconf :

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {
    'latest': LatestEntries,
    'categories': LatestEntriesByCategory,
}

urlpatterns = patterns('',
    # ...
    (r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
        {'feed_dict': feeds}),
    # ...
)

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

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

urlpatterns = patterns('',
    # ...
    (r'^feeds/latest/$', LatestEntries()),
    (r'^feeds/categories/(?P<category_id>\d+)/$', LatestEntriesByCategory()),
    # ...
)

Если вы в настоящее время используете feed()представление, LatestEntriesкласс часто не нужно изменять, кроме создания подкласса нового Feedкласса. Исключение, если Django автоматически разработка имени шаблона используется для визуализации описания и названия элементов фида (если вы не указав title_templateи description_templateатрибутов). Вы должны убедиться , что вы всегда указывать title_templateи description_template атрибуты, или предоставлять item_title()и item_description()методы.

Однако LatestEntriesByCategoryиспользует get_object()метод с bitsаргументом, чтобы указать конкретную категорию для отображения. В новом Feedклассе get_object()метод принимает requestаргументы и из URL-адреса, поэтому он будет выглядеть так:

from django.contrib.syndication.views import Feed
from django.shortcuts import get_object_or_404
from myproject.models import Category

class LatestEntriesByCategory(Feed):
    def get_object(self, request, category_id):
        return get_object_or_404(Category, id=category_id)

    # ...

Кроме того, get_feed()метод Feedклассов теперь принимает разные аргументы, что может повлиять на вас, если вы используете Feed классы напрямую. Вместо того, чтобы просто принимать необязательный urlаргумент, теперь он принимает два аргумента: объект, возвращаемый его собственным get_object()методом, и текущий requestобъект.

Чтобы учесть, что Feedклассы не инициализируются для каждого запроса, __init__()метод теперь по умолчанию не принимает аргументов. Раньше он брал бы slugиз URL и requestобъекта.

В соответствии с передовой практикой RSS, RSS-каналы теперь будут включать atom:linkэлемент. Возможно, вам придется обновить свои тесты, чтобы учесть это.

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

ID технических сообщений ¶

До версии 1.1 Django использовал идентификаторы технических сообщений, чтобы предоставить локализаторам возможность переводить форматы даты и времени. Они были переводимые строки перевода , которые могут быть признаны , потому что они были в верхнем регистре (например DATETIME_FORMAT, DATE_FORMAT, TIME_FORMAT). Они устарели в пользу новой инфраструктуры локализации Format, которая позволяет локализаторам указывать эту информацию в formats.pyфайле в соответствующем каталоге.django/conf/locale/<locale name>/

GeoDjango ¶

Чтобы обеспечить поддержку нескольких баз данных, внутреннее устройство базы данных GeoDjango было существенно изменено. Самым большим обратным несовместимым изменением является то, что модуль django.contrib.gis.db.backendбыл переименован в django.contrib.gis.db.backends, где теперь существуют полноценные серверные части пространственной базы данных . В следующих разделах представлена ​​информация о наиболее популярных API, на которые повлияли эти изменения.

from django.contrib.gis.db.backend.postgis import PostGISAdaptor

from django.db import connection
PostGISAdaptor = connection.ops.Adapter

>>> from django.db.models import get_app, get_models
>>> get_models(get_app('gis'))
[]

>>> from django.db import connections
>>> SpatialRefSys = connections['my_spatialite'].ops.spatial_ref_sys()
>>> GeometryColumns = connections['my_postgis'].ops.geometry_columns()

sr_qs = SpatialRefSys.objects.using('my_spatialite').filter(...)
gc_qs = GeometryColumns.objects.using('my_postgis').filter(...)

Код языка no¶

Используемый в настоящее время языковой код для норвежского букмола noзаменяется более распространенным языковым кодом nb.

Загрузчики шаблонов на основе функций ¶

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