качество и надёжность с 2008 года

8 (800) 200-25-11

Техническая поддержка support@komtet.ru —

круглосуточно и без выходных дней

load-whois

Онлайн-касса

для интернет-магазина

Подключите ваш интернет-магазин

к онлайн-кассе в соответствии с 54-ФЗ

Релиз Django 1.2 alpha 1

В статье "Django 1.2 alpha 1 release notes" автор говорит об основных изменениях, которые вошли в данную альфа-версию, а также указывает примерные сроки выхода окончательного релиза.

Добро пожаловать на Django 1.2 alpha 1!

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

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

Изменения без обратной совместимости в релизе Django 1.2

CSRF-защита

Были сделаны большие изменения в работе защиты от CSRF (Cross-site request forgery), детально изложенные в документации CSRF. Вот основные изменения, о которых должны знать разработчики:

  • CsrfResponseMiddleware и CsrfMiddleware устарели и будут полностью удалены в Django 1.4, в пользу тега, который должен быть вставлен в форму.
  • Все contrib-приложения используют csrf_protect decorator для защиты view. Это требует использования тега csrf_token в шаблоне, поэтому, если Вы использовали настраиваемые шаблоны для contrib views, Вы ДОЛЖНЫ ПРОЧЕСТЬ ИНСТРУКЦИИ чтобы исправить эти шаблоны.
  • CsrfViewMiddleware входит в MIDDLEWARE_CLASSES по умолчанию. Поэтому CSRF защита включается по умолчанию, так, что views, которые принимают POST-запросы, должны быть написаны для работы с middleware. Инструкции о том, как это сделать, можно посмотреть в документации CSRF.
  • CSRF-код, связанный с CSRF перемещён из пакета contrib в core (с обратной совместимостью импорта в старом местоположении, которые являются устаревшими).

Изменение поведения тега if

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

Класс LazyObject

LazyObject - является вспомогательным классом, который используется для "ленивой" упаковки других объектов неизвестного типа. Более ранние версии, чем Django 1.1 работали с интроспекцией нестандартным способом, в зависимости от упакованных объектов, которые применяют метод get_all_members(). Поскольку из-за этого мог легко возникнуть конфликт имён, то стали использовать стандартный способ, включающий в себя __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__())

Model__dict__

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

Field get_db_prep_*()

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

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

    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 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):
        # ...

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

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

Были предоставлены функции преобразования, которые прозрачно преобразуют функции старого типа в новые. Однако, эта функция преобразования будет удалена из Django 1.4, поэтому вам следует обновить определения полей (Field definitions), чтобы использовать новый тип функции.

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

теги шаблонов, хранящие состояние (Stateful template tags)

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

Все встроенные в Django теги безопасны для использования с загрузчиком кешированных шаблонов, но если вы используете настраиваемые теги в шаблонах, которые приходят из пакетов сторонних разработчиков, или написаны вами, то вы должны убедиться, что реализация узла (Node) для каждого тега является потоко-безопасным.  Для получения дополнительной информации см. template tag thread safety considerations.

Кода статуса завершения Запускателя тестов (Test runner)

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

Устаревшие возможности в версии 1.2

Middleware перезаписи CSRF в ответе

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

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

SMTP-соединение

Класс SMTPConnection был заменён на общее E-mail API бэкэнда. Вот пример старого кода, который явно иллюстрирует SMTP-соединение:

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

должен теперь вызывать get_connection() для создания экземпляра generic e-mail connection:

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

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

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)

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

До версии 1.1, 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',
    }
}

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

Старые настройки Новые настройки
DATABASE_ENGINE ENGINE
DATABASE_HOST HOST
DATABASE_NAME NAME
DATABASE_OPTIONS OPTIONS
DATABASE_PASSWORD PASSWORD
DATABASE_PORT PORT
DATABASE_USER USER
TEST_DATABASE_CHARSET TEST_CHARSET
TEST_DATABASE_COLLATION TEST_COLLATION
TEST_DATABASE_NAME TEST_NAME

 

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

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

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')

То же самое относится и к globals в django.forms.fields:

  • DEFAULT_DATE_INPUT_FORMATS
  • DEFAULT_TIME_INPUT_FORMATS
  • DEFAULT_DATETIME_INPUT_FORMATS

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

Что нового в Django 1.2 alpha 1

Следующий новый функционал присутствует в  альфа-релизе; этот релиз также знаменует собой окончание развития основного функционала для цикла релизов версии 1.2. Однако, некоторый второстепенный функционал продолжит своё развитие до beta-версии релиза 1.2.

Поддержка CSRF

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

E-mail-бэкенды

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

Это также облегчает отладку отправки почты - Django поставляется с бэкэндом, что позволяет вам отправлять почту в файл, консоль, память или просто «выбрасывать».

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

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

Поддержка множества баз данных

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

'Умный' тег if

Чтобы тег if был более мощным, он был обновлён. Сначала была добавлена поддержка операторов сравнения.  Вам больше не придется вводить:

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

...поскольку Вы теперь можете сделать следующее:

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

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

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

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

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

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

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

Натуральные ключи в fixtures

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

BigIntegerField

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

Приостановка тестов после первой неудачи

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

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

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

Добавлен readonly_fields в ModelAdmin

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

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

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

The Django 1.2 roadmap

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

  • Последняя неделя января 2010: Первый beta-релиз Django 1.2. Завершение добавления новых возможностей Django 1.2.
  • Первая неделя марта 2010: Первый релиз-кандидат Django 1.2. Завершение изменения строк для переводов.
  • Вторая неделя марта 2010: Окончательный релиз Django 1.2.

В случае необходимости будет опубликован дополнительный альфа, beta или релиз-кандидат, до выхода окончательного Django 1.2., который выйдет приблизительно через неделю после окончательного релиза-кандидата.

Что Вы можете сделать, чтобы помочь нам

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

Пожалуйста, откройте новый тикет, если нет темы, схожей с вашей проблемой.

Кроме того, обсуждение развития Django, включая продвижение к созданию релиза 1.2, можно увидеть в ежедневной рассылке django-разработчиков:

... и в #django-dev IRC-канале на irc.freenode.net. Если Вы заинтересованы помочь с развитием Django, присоединяйтесь к обсуждениям.

Интерактивная документация Django также включает в себя рекомендации о том, как внести свой вклад в Django:

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

Спринты по развитию Django 1.2 будут также иметь место на конференции в Атланте (США) PyCon US 2010 (22 - 25 февраля), и любого, кто хочет помочь, мы просим присоединяться либо лично на конференции PyCon, или виртуально через IRC-канал,  или через списки рассылки.

 

Оригинал статьи на docs.djangoproject.com

Перевод КОМТЕТ komtet.ru

Другие документы на эту тему

Виртуальный хостинг Perl/PHP/Python/Ruby

Тарифные планы «Виртуальный хостинг» — от размещения статических HTML-страниц, до поддержки PHP, Python, CGI скриптов (Shell, Perl), SSI, Ruby. В рамках тарифных планов предоставляется доступ к серверам баз данных MySQL или PostgreSQL.

Django

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

Пути к интерпретаторам Python и фреймворкам Django, TurboGears, Pylons

В данной статье приведён список путей для всех версий Python и фреймворков Django, Pylons, TurboGears, доступных на хостинге.

Скидка 30% на SSL-сертификаты!
Клиентам — домены в подарок!
Бесплатный тест виртуального хостинга
Перенос сайта — бесплатно
Все акции
На сайте КОМТЕТ используются cookie-файлы, данные о IP-адресе и местоположении посетителей. Если, прочитав это сообщение, вы остаетесь на нашем сайте, это означает, что вы не возражаете против использования этих технологий.