livedev.org

На пути к 1.0 релизу Django претерпевал немало радикальных изменений. Одно из них рефакторинг системы сигналов.

Если вы первый раз читаете и не в курсе «что это такое и с чем его едят», то скажу в двух словах. Это система реагирования на события приложения. Любой JavaScript или прикладной UI программист хорошо знаком с системой событий (event) — клик мышкой, нажатие горячей клавиши и т.п. Для программистов серверной части веба все выглядит немного по другому. Есть HTTP-запрос и есть его обработчик, анализируется как правило URL на предмет «кому отправлять запрос». Но на самом деле это та же система сигналов-событий, только узкопрофилированная под обработку HTTP-запросов.

Оказывается серверная часть веб-приложения тоже может, и я уверен, просто должна генерировать намного больший спектр сигналов, чем просто обработку URL и данных запроса. С чем успешно и справляется Django. Теперь немного прозы. Какие же события может ловить Django «из-коробки».

• pre_init — перед запуском метода-конструктора __init__() модели;
• post_init — после выполнения метода __init__() модели;
• pre_save — перед сохранением экземпляра модели в базу;
• post_save — после успешного сохранения экземпляра модели в базу;
• pre_delete, post_delete — перед и после удаления экземпляра модели из базы;
• post_syncdb — генерируется админкой Django после установки нового приложения (INSTALLED_APPS);
• request_started, request_finished, got_request_exception — генерируются при обработке HTTP-запросов;
• template_rendered — генерируется только в режиме тестирования приложения.

Итак сигналы *_init, _*save, *_delete и post_syncdb генерируются системой моделей Django и их можно импортировать из django.db.models.signals. Сигналы обработки HTTP-запросов из django.core.signals. И тестовый template_rendered из django.test.signals.

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

Код модели:

class MimeType(models.Model):
    """
    Mime Types table
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()

    def __unicode__(self):
        return self.name

class Item(models.Model):
    """
    Main file
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()
    file = models.FileField(upload_to='files', blank=True)
    mime = models.ForeignKey(MimeType, blank=True, null=True)
    upload_date = models.DateTimeField(auto_now_add=True)

    def __unicode__(self):
        return self.name

    def set_mime(self, mime):
        obj, created = MimeType.objects.get_or_create(name=mime, slug=slugify(mime))
        self.mime = obj

Посмотрите на метод set_mime модели Item. Он создает новый объект MimeType или использует если он уже создан. При этом не сохраняя модель Item. Теперь я пишу функцию-callback, которая будет вызываться по событию сохранения модели Item.

import mimetypes
import os.path

# init mime types dict
mimetypes.init()

def add_mime_type(instance, **kwargs):
    """
    Adding mime-type to uploaded file (for future use).
    Would be called on post-save.
    """
    if not hasattr(instance, 'mime') or not hasattr(instance, 'file'):
        raise Exception("Object %s does not have 'mime' attribute! Can't set mime-type!" % instance)
    if instance.file:
        extension = os.path.splitext(instance.file.path)[1].lower()
        instance.set_mime(mimetypes.types_map[extension])

Итак, функция-callback add_mime_type принимает параметр instance, который является экземпляром модели, сгенерировавшим сигнал (в нашем случае модели Item). Вторым параметром принимает словарь (dictionary). Кстати, это и есть один из моментов обратной несовместимости. После рефакторинга каждая функция-callback должна принимать параметр **kwargs.

Теперь третий самый простой шаг — связывание модели с сигналом. В самом конце файла моделей добавилась строчка:

models.signals.pre_save.connect(add_mime_type, sender=Item)

Теперь перед каждым сохранением объектов Item, будет выполняться проверка и установка Mime-типа.

Кстати, я советую если у вас больше одного сигнала, выносите их в отдельный файл signals.py или можно по-старинке писать в файле моделей (что ИМХО иногда мешает чтению кода).

Почитать про сигналы можно еще в официальной доке: Django Signals и Django Built-in signal reference. Почитать про рефаторинг можно на странице Backwards Incompatible Changes и в соответствующем коммите 8223.

Александр Кошелев тоже немного раньше написал по теме, статья «А вы поймали новые сигналы?» с хорошим примером создания абстрактного сигнала.

«На сегодня все. Вопросы в студию» :-)

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

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

• эффективное создание форм;
• кастомизация django admin интерфейса;
• трюки с FileField и аплоадом в общем;
• сигналы в django.

Вышла новая переписанная версия Spawning — WSGI сервера. Главное достоинство это non-blocking IO, т.е. большие возможности по масштабируемости (scaling).

Spawning is a wsgi server which supports multiple processes, multiple threads, non-blocking HTTP io, and automatic graceful upgrading of code.

Это очередной способ запуска django и других python-приложений для веб. Пример команды для запуска django процесса:

spawn --factory=spawning.django_factory.config_factory settings --port 9090 -s 4 -t 100

Пример для запуска приложений через paste (например Pylons используют paste для деплоя):

spawn --factory=spawning.paste_factory.config_factory development.ini

Если захотелось поставить и попробовать:

sudo easy_install Spawning

Почитайте еще обзор Эрика на английском.

Update: как ни странно товарищ Александр aka piranha практически одновременно со мной написал статью как раз про деплой через WSGI. Так что моя заметка «пролетает как фанера над Парижем», ибо мягко говоря Spawing не самый быстрый вариант :-) Читайте — Amazon byteflow: WSGI серверы кратко и юзайте fapws2.

Скажу сразу: «я офигел». То, что сейчас предлагает Google для сторонних разработчиков — просто бомба. И не думайте, что App Engine это что-то новое. Да это неплохое дополнение к существуещей инфраструктуре, но самое главное внутри.

Итак, про что же я. GData — универсальный API Google для чтения, записи и поиска в его сервисах. Это очень сбалансированная смесь CRUD и Atom/RSS. Самое главное в GData — это фиды. Результаты поиска, сложные запросы, создание/обновление документов и т.п. возвращаются в формате, подобному Atom фиду. Ребята из Google практически дополнили спецификацию Atom возможностью делать запросы (выборки) и реализовали незаконченную спецификацию Atom Publishing Protocol. Другими словами гугловские сервисы видны через интерфейс GData, как фиды, которые можно читать, апдейтить, искать по каким-то параметрам и удалять. Эта модель работы с данными отлично вливается в сферу веб, что и показала практика Web2.0 (покажите популярный сайт без фида).

Какие сервисы на сегодня доступны через GData API:

• Google Docs;
• Gmail contacts;
• Notebook;
• Blogger;
• Picasa;
• Calendar;
• Base;

Полный список на сайте Google API.

Чтобы не остаться голословным хочу привести пример кода для работы с Google Docs.

import gdata.docs.service

# авторизация
gd_client = gdata.docs.service.DocsService()
gd_client.email = 'username@gmail.com' #change this
gd_client.password = '' #change this
gd_client.source = 'exampleCo-exampleApp-1'
gd_client.ProgrammaticLogin()

# запрашиваем список (фид) всех документов с сервиса
feed = gd_client.GetDocumentListFeed()
# выбираем первый документ для работы
d = feed.entry[0]
# работаем с документом
print d.title.text # выводим название документа
print d.content.src # ссылка на документ в html виде (как он хранится в google)

Для создания или изменения документа необходимо использовать python-модуль atom. Пример кода:

import atom
# устанавливаем название нового документа
document.title = atom.Title(text='my best friends')

Что еще можно добавить. Вышеприведенный код предоставлен разработчиками Google для Python. Т.е. это уже клиентская часть API. Есть также версия для Java, .NET и PHP. Так что если есть желание интегрироваться с Google, то, пожалуй, все необходимое для этого есть.

Вывод простой. Google превращается из робота индексера в датацентр для размещения информации и вычислений. На сегодняшний день — это работа с документами, почтой, контактами, блогами и фото. Все в одной среде. И новое API — это отличный вариант реализации интерфейса к фичам этого гугло-датацентра :-)

На закусь ссылка на описание протокола GData.

Свежая новость про новый сервис от Гугла. Я не удивлен — Гугл предлагает хостинг приложений. Вполне логичное развитие. Я в принципе давно этого ждал. Что хорошего и что плохого? Много писать не буду.

Хорошее — мощнейшая инфраструктура для хостинга и конечно поддержка приложений на Python ;-)

Плохое — такими темпами скоро «Интернет» == «Google». Я имею довольно приличный опыт в телекоме и хорошо понимаю, что бояться нужно совсем не того что Google индексирует все на свете и типа приватности скоро кирдык. А бояться нужно того, что Гугл сосредоточит большое кол-во интернет-траффика на себе и в результате сможет диктовать свои условия провайдерам. И скорее всего мы получим большое кол-во шаровых вещей в обмен на бесконечный поток контекстной рекламы... Так обычно Гугл и делает. Но не будем о грустном, время покажет.

Подробнее смотрите на страницах Гугла:

• Google App Engine - Google Code
• Google App Engine Blog: Introducing Google App Engine + our new blog
• Running Django on Google App Engine - Google App Engine - Google Code

Тему я зацепил острую, так что будем наяривать дальше :-). Не думайте, что тематика блога сменится на php vs *. Нет, скажу пару мыслей и дам несколько ссылок. Думаю на ближайшее будующее этого хватит.

Итак, читайте пост Николая про субъективные причины выбора языка Python для веб-разработки — Блог компании SmartWeb: Почему Python (Муки выбора). Коменты пестрят конечно, но обратите внимание, что ребята целой командой писали до этого на Java, а не на php.

Советую послушать подкаст Димы Честных — Python против PHP. С юмором и по теме.

И немного наблюдений от себя. Последнии пару недель я получил достаточно много разного фидбека по теме корявости php. Так что получилась некоторая закономерность в общении. Итак, немного фактов.

• Примерно 50% утверждавших, что php «рулит», не знают никакого другого языка программирования.
• Около 20% счастливы от самого факта перехода с enterprise (Java, .NET) технологии на динамический язык (php) и пока не осознали, что его им мало.
• Около 25-30% процентов считают отсутствие поддержки python или ruby хостинг-провайдерами причиной для торможения личного развития, как программиста.
• Больше половины писавших на каком-то другом языке программирования перед php, долго на php не задерживаются.

И в довесок хочу дать ссылку на хорошую новую документацию, точнее даже набор примеров работы на python с мелкими задачами — Python-by-example. Оглавление разбито по python-модулям. Ну и конечно, если кто-то решил ознакомиться с python или собирается начать писать что-то на нем, и при этом не знает с чего начать, могу посоветовать книгу В глубь языка Python. Я в свое время начал с придуманной мной самим задачи и официальной документации :-)

Сегодня важное событие у меня. Я наконец-то смог выродить подкаст о веб-разработке, который планировал оч давно записать. Даже не только планировал, но и пробывал. Итак, это моя третья попытка — более-менее удачная. Не могу сказать что я на 100% доволен результатом, но как говориться «первый блин можно и простить» :-)

Для меня намного важнее узнать ваше мнение, уважаемые читатели! На сколько вам был бы полезен вообще подкаст о веб-разработке. И о каких темах вы бы хотели услышать выпуски в будующем. Любые ваши комментарии (желательно конструктивные) будут мотивировать меня для дальнейшей записи. А так как я не диктор и не работал никогда на радио, дается мне сие записывание нелегко... Так что хотелось бы знать интересно ли будет что-то подобное для вас. Жду фидбека, а пока качайте 10 минутное mp3 весом в 14Мб :-)

Отдельный фид для подкаста скоро будет.

Update: сделал еще копию подкаста с битрейтом 128 на 10Мб

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

• Google GData Authentication decorator — пример кода для работы с документами google на python (удобный декоратор).
• Control Suite : High Quality Controls & Widgets for Prototype — интересный набор контролов и виджетов для javascript библиотеки Prototype.
• FastInit: a faster window.onload — готвый javascript код (кроссбраузерный) для убыстренной инициализации и вызова js-скриптов. Очень удобно использовать вместо window.onload.
• Cross-Fade Anything — еще одна javascript библиотека для создания слайд-шоу эффекта в Prototype.
• Ext JS - JavaScript Library — очередной javascript тулкит для создания rich ui. Особенность в том, что он позволяет строить оконные интерфейсы aka browser OS.
• LightWindow — реинкарнация популярного Lightbox JS. Позволяет делать js popup с любым контентом, в отличии от lightbox, который позволяет делать popup только картинки.

PS: если вы использовали что-то из указанного в ссылках — поделитесь, пожалуйста. Думаю многим будет интересно узнать чужое мнение.

Наткнулся на интересную заметку. Как автоматизировать загрузку всех моделей из INSTALLED_APPS при запуске django python shell (manage.py shell).

from django.db.models.loading import get_models
for m in get_models():
    exec "from %s import %s" % (m.__module__, m.__name__)

Оказывается очень удобно! :-)

Оригинал — Peter Sheats’ Blog » Blog Archive » Autoloading Your Django Models

Решил сменить свою del.icio.us ленту в сайдбаре на более-менее регулярный постинг интересных ссылок.

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

Итак интересное, что я «нарыл» на просторах интернета за последние пару недель.

• StaticGenerator for Django — ссылка дня! очень полезный проект для django-разработчиков, может генерировать статический html вариант сайта из моделей, пользуясь методом get_absolute_url. Самое главное, что через сигналы он может автоматом обновлять html-страницы при изменении/добавлении объектов (т.е. буквально данных в базе).
• Evaluation of web based WYSIWYG-editors, test result 2007 — обзор онлайновых WYSIWYG редакторов (javascript и один на java), с него набрел на один интересный редактор (следующая ссылка).
• WYMeditor - web-based XHTML editor — простой интересный онлайн редактор, без возможности upload/insert images, но зато более семантичный и наглядный для тех, кто знает HTML.
• WYMstyle и css-boilerplate — css frameworks, хороши для веб проектов, когда у вас еще нет дизайна веб-сайта/веб-приложения, но вам нужно более-менее симпатично показать контент и функционал. Облегчают работу тем, кто не любит долгой возни с версткой.
• swfobject 2 — новая переработанная версия (на данный момент rc1) javascript библиотеки для включения в страницу flash/flex роликов или приложений. Кто еще не пробывал — советую, намного удобнее, чем писать кроссбраузерные теги и делать ручные проверки нужной версии flash. Еще можно почитать блог разработчиков — SWFFix Dev Blog.
• transdb — неплохая библиотека для локализации конента в django. Добавляет специальные многоязыковые текстовые поля в модель, что облегчает работу с базой и хорошо интегрируется с существующей системой i18n в django.
• PyAMF — Реализация на Python поддержки протокола обмена данными AMF (от Adobe) для клиент-серверного взаимодействия. Используется во flash и других проектах Adobe. Данные по этому протоколу передаются в бинарном виде, что более-продуктивно с точки зрения потребления траффика, автоматизирована сериализация/десериализация данных как на стороне сервера, так и клиента.