Еще один блог о Django

Проверяем значение переменной на True, False, None в Django шаблонах

2011-09-12T22:24:00.000+03:00

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

Но сегодняшний инцидент стоит просто за гранью моего понимания. Итак, есть модель с полем NullBooleanField, назовем его verified. Далее в шаблоне нужно отображать специфический класс для HTML-тега если verified is False. Что ж, это просто, за неимением is возпользуюсь проверенным ==:

<div{% if verified == False %} class="ui-state-error-text"{% endif %}>
    Some text
    Some input
</div>

Ок, обновляю страницу и думаю все ок. Однако, не тут-то было. Результата нет, в исходном тексте тоже никакого class="ui-state-error-text" нет и в помине. Странно. Ладно, дай думаю проверю в shell_plus. Проверка подтверждает мои опасения:

In [2]: t = Template('{% if verified == False %}False{% else %}Not False{% endif %}')

In [3]: t.render(Context({'verified': False}))
Out[3]: u'Not False'

In [4]: t.render(Context({'verified': True}))
Out[4]: u'Not False'

In [5]: t.render(Context({'verified': None}))
Out[5]: u'False'

Хм, ясное дело свитч на {% if not verified %} не достиг никаких результатов (теперь класс будет печататься и в случае, когда verified is None):

In [6]: t = Template('{% if not verified %}False{% else %}Not False{% endif %}')

In [7]: t.render(Context({'verified': False}))
Out[7]: u'False'

In [8]: t.render(Context({'verified': True}))
Out[8]: u'Not False'

In [9]: t.render(Context({'verified': None}))
Out[9]: u'False'

Хм, что же делать? Как же быть? Почему {% if verified == None %} работает если verified is None. Спросил совета у команды. И надо сказать их совет подействовал, надо просто проверку на False сменить на проверку на 0. И все начинает работать:

In [10]: t = Template('{% if verified == 0 %}False{% else %}Not False{% endif %}')

In [11]: t.render(Context({'verified': False}))
Out[11]: u'False'

In [12]: t.render(Context({'verified': True}))
Out[12]: u'Not False'

In [13]: t.render(Context({'verified': None}))
Out[13]: u'Not False'

Теперь вопрос, что заставило Django-девов не добавить boolean константы True и False в {% if %} темплейт тег? Где поддержка var is (None|True|False)? Уже ж сделали вроде как вменяемый if, что помешало сделать это раз и навсегда? Особенно в свете того, что поддержка конструкций item in list и item not in list была добавлена.

В целом был разочарован я изрядно, но теперь буду помнить, что для проверки на True, False в шаблонах надо сравнивать с 1 и 0. Прям как хрен знает где еще :(

Уменьшаем кол-во запросов, которые генерируются Django ORM

2011-06-23T17:37:00.000+03:00

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

Лирическое отступление: Для того, чтоб лучше понять как эти методы работают, я задам легкую схему для моделей, упоминаемых в статье. Во-первых, это будет встроенная auth.User, затем это будет модель статьи, которая будет версионироваться при помощи django-reversion. Иными словами, наш models.py будет выглядеть как-то так:

from django.db import models
from django.utils.translation import ugettext_lazy as _

import reversion


class Article(models.Model):

    STATE_NEW, STATE_SUBMITTED, STATE_REJECTED, STATE_ACCEPTED = range(1, 5)
    STATE_CHOICES = (
        (STATE_NEW, _('New')),
        (STATE_SUBMITTED, _('Submitted')),
        (STATE_REJECTED, _('Rejected)),
        (STATE_ACCEPTED, _('Accepted)),
    )

    title = models.CharField(_('title'), max_length=64)
    content = models.TextField(_('content'))
    state = models.PositiveIntegerField(_('state'), choices=STATE_CHOICES,
        default=STATE_NEW)

    writer = models.ForeignKey('auth.User', related_name='articles_writer',
        verbose_name=_('writer'))
    editor = models.ForeignKey('auth.User', blank=True, null=True,
        related_name='articles_editor', verbose_name=_('editor'))

reversion.register(Article)

Метод 1. Использование select_related вместо all

Здесь все очень просто. Если у моделей есть не-нулевые FK поля Вы явно захотите получать данные в них без дополнительных запросов к БД. Потому если писатель статьи должен быть явно указан на сайте, то считывайте статьи перед паджинацией как,

articles = Article.objects.select_related()

а не .all(). На самом деле метод .all() хорош как по мне только для "нишевых" (с малым кол-вом или вообще без связей) моделей. В остальных случаях надо смотреть по ситуации, может где-то .defer() после .select_related(*fields) пригодится, может где и .annotate() будет использован.

В целом с .select_related() я думаю всем все давным давно ясно, не забывайте только, что для не-нулевых FK-полей этот метод ничего не даст. И следующий код сгенерит в худшем случае Articles.objects.count() + 1 запросов (если все поля editor заполнены), вместо 1:

articles = Article.objects.select_related()
for article in articles:
    print(article.title, article.state, article.writer, article.editor)

Метод 2. Использование model.fk_id вместо model.fk.id

На самом деле, с первого взгляда кажется, что метод несколько бесполезен. Ну что там можно узнать про объект только по его идентификатору? Однако, смею вас уверить, это кажется только на первый взгляд. На самом деле во всяких filter или map и прочих lambda-функциях без него не обойтись.

Простой пример, необходимо найти все версии, оставленные редактором статьи. Что сразу приходит в голову? Использовать простой запрос,

article = Article.objects.get(pk=XXX)
versions = Version.objects.get_for_object(article).\
                           exclude(revision__user=None)
versions = article.editor and versions.filter(revision__user=article.editor) \
                          or versions.none()

И вроде все просто и безоблачно. Но только до поры до времени, для начала это +1 запрос к БД, а потом код переместиться в цикл или надо будет расширить параметры поиска искать не только ревизии редактора, но и какого-то системного пользователя.

Выход прост, изначально помнить, что редактор может принимать нулевое значение, а значит обращение к .editor спровацирует +1 запрос к БД. А значит используем .editor_id и точно знаем, что здесь искать кита мы не будем.

article = Article.objects.get(pk=XXX)
versions = Version.objects.get_for_object(article).\
                           exclude(revision__user=None)
versions = \
    article.editor_id and versions.filter(revision__user__pk=article.editor_id) \
                      or versions.none()

Метод 3. Предопределение FK значения

Сразу предупреждаю, пользуйтесь этим методом осторожно и только если уверены, что знаете что делаете :)

Помните пример из первого метода? Когда каждый запрос к полю редактора статьи стоил нам одного запроса. Нехорошо это, ведь и .select_related() нам тут не помощник. Но, не все так печально, а иначе очень уж просто. Надо всего лишь считать всех пользователей, а потом подставить необходимое значение в аттрибут ._editor_cache (примечание: на месте editor может быть любое название вашего FK-поля). А теперь еще раз и в коде:

articles = Article.objects.select_related('writer')
users = User.objects.all()
users = dict([(user.pk, user) for user in users])

for article in articles:
    article._editor_cache = users.get(article.editor_id)
    print(article.title, article.state, article.writer, article.editor)

И мы в итоге получаем гарантировано два запроса к БД, вместо Article.objects.сount() + 2 в худшем случае (опять же при условии, что все поля editor заполнены). Просто и изящно.

Однако надо помнить, что установив ручками значение в ._{{ fk_field }}_cache именно вы в ответе за него, а никак не Django. И если вдруг редактором статьи вместо Васи Пупкина станет Джон Доу, то вы знаете что делать :)

Метод 4. Ручное исполнение запросов

Я думаю, многие обрадовались и подумали, ну наконец-то про .raw(), ну наконец-то про SQL, к черту тот ORM, он и медленный и вообще сложно с ним. Но нет, поспешу разочаровать. Я лишь про то, что во многих случаях может пригодится явное преобразование QuerySet объектов в что-то более питоновское, как-то list и в дальнейшем использование именно питоновских функций для выборки данных, например filter(), а не метода .filter(). Взвесьте все за и против и помните, что QuerySet преобразованный в list ~~есть не попросит~~ к базе уже не обратиться, а обыкновенный еще как сможет.

Ну и про .raw() и .extra() не забывайте. Как говорится, есть моменты когда ваше SQL кунг-фу будет сильнее SQL кунг-фу Django ORM.

Метод 5. Или прочее

Сразу оговорюсь, что я не пытался упомянуть о всех методах уменьшения кол-ва запросов, а лишь хотел преподнести вам методы наиболее используемые мною при работе с Django. Для дальнейшего просветления я рекомендую вам прочитать раздел про оптимизацию доступа к базе данных в документации Django (версия для 1.3 или 1.2), ну или напрямую обращаться к Google или StackOverflow с теми же ключевыми словами, Django database optimization.

На сим прощаюсь и до новых встреч. Если появились вопросы или я где-то сглупил - милости прошу в комменты!

Заставляем кастомные поля для моделей работать под Django 1.2+

2010-11-24T15:21:00.001+02:00

Некоторое время тому назад я разработал несколько кастомных полей для моделей, таких как PickleField и JSONField и все было в них хорошо. Но время ведь не стоит на месте и мне захотелось окончательно перейти в своих проектах на прекрасную Django 1.2+ и использовать ее бенефиты вместе с использованием моих старых кастомных полей.

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

Открыв документацию, я понял, что был прав. Проблема была в том, что при переходе на поддержку многих БД одновременно был совершен рефакторинг get_db_prep_value и подобных ему методов. Для них были добавлены аргументы connection, prepared=False и пользоваться ими рекоммендовалось только в случае БД-зависимого преобразования. А БД-независимые преобразования советовали делать в get_prep_value и подомных ему методов.

Так как мои поля не требовали БД-зависимого преобразования, я решил просто переименовать свои get_db_prep_value методы в get_prep_value. Результат не заставил себя долго ждать и при следующем перезапуске, тесты моделей, содержащие кастомные поля, прошли без ошибок. Все бы хорошо, но не выбрасывать же поддержку кастомных полей для версий Django ниже 1.2.

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

class PickleField(models.Field):
    ...
    def get_db_prep_value(self, value, **kwargs):
        return self.get_prep_value(value)

    def get_prep_value(self, value):
        return pickle.dumps(value)
    ...

Да, это решило проблему с прохождением тестов для Django < 1.2, но теперь тесты стали валиться на Django 1.2+. Видно что-то было не так. Вооружившись дуростью, я начал копать в сторону неправильного генерирования SQL-запроса. И так бы продолжалось долго, если бы я не остановился и не подумал еще раз посмотреть на отрефакторенный код get_db_prep_value метода. После этого проблема стала очевидной, мое предыдущее решение просто дублировало преобразование значения и потому Django не могло найти записи в базе данных и возвращало ObjectDoesNotExist.

Что ж после определении проблемы надо было немного подумать над ее решением, но я не стал себя заморачивать и просто для всех кастомных полей и версии Django меньше 1.2, я переименовал методы get_prep_value в get_db_prep_value при помощи следующего кода:

from django import VERSION


if VERSION[0] == 1 and VERSION[1] < 2:
    fields = (JSONField, PickleField)
    for field in fields:
        if not hasattr(field, 'get_prep_value'):
            continue
        field.get_db_prep_value = field.get_prep_value
        del field.get_prep_value

Последующий перезапуск тестов на 1.0.4 и 1.1.2 завершился успехом, впрочем как и для 1.2.3 и версии из транка.

Конечно, мне не особо нравится эта магия, но у разработчиков Django похоже не было другого выбора для реализации рефакторинга, посему имеем то, что имеем :)

И опять про PickleField

2010-03-31T15:24:00.009+03:00

Давным-давно я написал более менее работающий пример PickleField'а - поля для хранения любого питоновского объекта, поддерживающего сериализацию при помощи pickle или cPickle.

И все бы неплохо, только на днях мне понадобилось хранить в этих PickleField'ах Django'вские модели, например экземпляры пользователей (auth.User) или проектов (самописная модель). Да, возможно, это не совсем верно, но задача стояла именно такая.

Не надеясь получить какой-то подвох я стал просто сохранять эти instance, и вроде бы все работало, пока я не написал смехотворный тест:

project = choice(Project.objects.all())
user = choice(project.users.all())

PickleModel.objects.create(object_field=project)
obj = PickleModel.objects.get(object_field=project)
obj.object_field = user
obj.save()

obj = PickleModel.objects.get(object_field=user)
obj.delete()

гдe PickleModel простая тестовая модель:

class PickleModel(models.Model):

    object_field = PickleField()

И каково было мое удивление, когда тест завершился ошибкой PickleModel.DoesNotExist на 9 строке вместо чистого прохождения. Интересно, сказал я и полез в код, смотреть почему PickleField при чистом сохранении (PickleModel.objects.create) правильно сохраняет в базу весь инстанс проекта, а при обновлении тестового объекта (obj.object_field = ...) сохраняет что-то не то и не так.

Сначала думал, что ошибка где-то в PickleField, на секунду даже задумался о использовании стороннего решения. Но потом понял, что сам PickleField не причем, и что при обновлении тестового объекта не вызывается PickleField.get_db_prep_save. Интересно, решил я и пошел смотреть на то, как именно проходит процесс обновления объекта в django.db.models.base.Models.save_base, а оттуда в django.db.models.base.sql.UpdateQuery.add_update_fields, где собственно и происходит процесс генерирования sql-запроса для обновления. Там я и нашел причину такого поведения Django.

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

Для начала решил по манки-патчить по-тупому, добавив в PickleField.to_python:

        if hasattr(value, 'prepare_database_save'):
            delattr(value, 'prepare_database_save')

на что Питон сказал мне: Are you crazy, man? И добавил AttributeError: prepare_database_save. Тогда я решил по манки-патчить более умно, в два захода :) Для начала подменил поведение prepare_database_save в том же PickleField.to_python:

        if hasattr(value, 'prepare_database_save'):
            value.prepare_database_save = \
                lambda unused: PickleField().get_db_prep_save(value)

а затем, в PickleField.get_db_prep_value возвращал объекту первичное состояния, чтобы его возможно было сериализовать:

        if hasattr(value, 'prepare_database_save') and \
           isinstance(getattr(value, 'prepare_database_save'),
                      types.LambdaType):
            delattr(value, 'prepare_database_save')

После всего этого, запустил исходный тест, порадовался чистому проходу и решил написать вот этот малость бессмысленный псот :)

Ах да, сам код PickleField доступен как всегда в kikola.db.fields, ну или отдельным гистом.

И еще одна забавная возможность PickleField'a. Благодаря модифицированию стандартного поведения get_default вы можете указывать любой питоновский объект, как дефолтное значение для этого поля. Например:

class PickleModel(models.Model):

    dict_field = PickleField(default={'a': 1, 'b': 2, 'c': 3})
    list_field = PickleField(default=[1, 2, 3])
    tuple_field = PickleField(default=(1, 2, 3))

Весьма полезная для меня возможность, подсмотренная в issues к django-extensions.

Апдейт

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

project = choice(Project.objects.all())

obj = PickleModel.objects.create(object_field=project)
obj.save()

obj = PickleModel.objects.get(object_field=project)

а именно в том, что если поле object_field осталось нетронутым при изменении модели, по при вызове save все-таки вызовется метод prepare_database_save и конвертирует модель в строку - первичный ключ.

Но не беда, манки-патчим django.db.models.Model.prepare_database_save и получаем работающий тест и код:

# Make able to store Django model objects in ``PickleField``
def picklefield(func):
    def wrapper(obj, field):
        if isinstance(field, PickleField):
            return field.get_db_prep_save(obj)
        return func(obj, field)
    return wrapper


models.Model.prepare_database_save = \
    picklefield(models.Model.prepare_database_save)

Хотя, по правде говоря, и это решение мне не очень нравится. Dirty hack, не иначе.

Разворачиваем проект при помощи virtualenv и pip

2010-01-23T14:44:00.002+02:00

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

Итак, на самом деле все просто. Для начала надо создать новое виртуальное окружение, а затем установить туда все зависимости. Также было бы неплохо получить Makefile со всеми необходимыми целями, которые будут облегчать работу с проектом.

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

$ virtualenv ENV

да:

$ pip install -E ENV -r REQUIREMENTS.pip

где REQUIREMENTS.pip - файл со всеми необходимыми зависимостями для проекта. Ну а потом прописать прямо в Makefile или в Makefile.def путь к "новому" Python'у, в нашем случае это может выглядеть как-то так:

PYTHON=ENV/bin/python

Но, когда новые проекты начинают сыпаться как из рога изобилия хочется автоматизировать все эти действия. Для этого я на коленке написал bootstrap скрипт. Разберемся с тем, что он делает.

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

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

В-третьих, скрипт создат для Вас новое виртуальное окружение, если оно еще не создано. По умолчанию, это виртуальное окружение создатся с опциями --no-site-packages --unzip-setuptools.

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

В-пятых, скрипт установит все зависимости, находящиеся, по умолчанию, в файле REQUIREMENTS.pip и сохранит все скачанные архивы с питоньими пакетами в ENV/src. Формат файлов зависимостей описан в документации к pip.

Собственно все. После обновления зависимостей или шаблона Makefile - просто выполните bootstrap.py еще раз and have fun.

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

Используем встроенные строковые методы Python'а в Django шаблонах

2009-12-02T00:14:00.009+02:00

Вместо предисловия

Привет! Давно здесь не отписывался. Почему? Наверное главная причина, что после выхода 1.1 версии уже не так активно слежу за развитием Django. Может быть в ближайшее время меня пробъет на творчество и я выдам пару-тройку новых постов, но не обещаю ;)

Но это я отвлекся от темы поста. А она заключается вот в чем. Надо было сегодня в шаблонах Django для некоторых урлов убрать конечные слеши, т.е. просто вызвать url.rstrip('/'). Просмотрев в который раз список всторенных шаблонных фильтров и не обнаружив там нужного, я задумался: как быть? Создавать простой фильтр, типа:

from django.template import Library
from django.template.defaultfilters import stringfilter


register = Library()


@register.filter
@stringfilter
def rstrip(text, chars=None):
    return text.rstrip(chars)

совершенно не хотелось. Ибо вдруг мне в будущем захочется добавить поддержку lstrip или strip метода. Что надо будет морочиться с Ctrl+C, Ctrl+V и минимальными исправлениями отяжеляя эту темплейт библиотеку?

Потому не долго думая и вроде бы не отыскав необходимого мне решения в гугле, я решил повелосипедить и добавить возможность вызова всех строковых методов Python в Django шаблоне.

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

from django.template import Library
from django.template.defaultfilters import stringfilter


register = Library()


for name in dir(u''):
    if name.startswith('_'): continue

    filter = lambda value, *args: getattr(unicode(value), name)(*args)
    filter = stringfilter(filter)

    register.filter(name, filter)

Написав простой тест-кейс я уже было приготовился доставать шампанское и переходить к следующей задаче, но не тут-то было :( TemplateSyntaxError для {{ url|strip:"/" }} заставила притормозить коней. Почему же так произошло? Я пошел к месту ошибки и понял, что проблема в *args, точнее в том, что django.template.FilterExpression.args_check ожидает определенный набор аргументов, а не, наоборот, не определенный заранее.

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

@stringfilter
def make_filter(name):
    def filter(value, first=None, second=None, third=None):
        args = [first, second, third]
        method = getattr(force_unicode(value), name)

        while True:
            try:
                return method(*args)
            except TypeError:
                args.pop(len(args) - 1)

    return filter

и заодно переписал регистрацию этого фильтра. Запустил тест-кейс, получил Ran OK! и на свою голову решил усложнить тест-кейс, проверив работу фильтра с двумя аргументами, например, {{ "abcdef"|replace:"abc":"def" }}.

Каково же было мое удивление, когда Django сказала, нет много аргументов для фильтров - это не хорошо. И сгенерировала очередную TemplateSyntaxError. Что ж, пришлось реализовывать это в виде отдельного простого тега {% stringmethod %}. Принцип его работы простейший, как видно из кода:

@register.simple_tag
def stringmethod(name, value, first=None, second=None, third=None):
    return make_filter(name)(value, first, second, third)

В свою очередь это повлекло за собой обновление теста, и {{ "abcdef"|replace:"abc":"def" }} превратилось в {% stringmethod "replace" "abcdef" "abc" "def" %}. Монструозно, соглашусь, но что поделаешь. В итоге, получив Ran OK! я немного подправил документацию и выложил это все дело, как отдельный гист на гитхаб.

Пользуйтесь, возможно вам это пригодится!

зы. На последок упомяну еще о пару особенностях stringmethods. Во-первых, она не переписывает встроенный join фильтр, во-вторых, она плохо справляется с format.

зыы. Если вы знаете reusable apps решающие похожие проблемы - не стесняйтесь писать в комменты :)

Sphinx documentation + GitHub pages = <3

2009-05-12T11:12:00.007+03:00

Вообщем буду краток ;)

Для документирования питоньих проектов очень удобно использовать Sphinx. Это всем известно. А если не известно, то и Python, и Django документированы именно им.

На GitHub'е есть возможность размещения HTML страниц проекта и последующего доступа к ним по адресу: http://username.github.com/repo_name/.

Само собой разумеется, было бы очень неплохо подружить их. И посему я на коленке написал следующую Makefile-команду:

project=YOUR_PROJECT_NAME
docs_dir=$(TMPDIR)/$(project)-docs

ghdocs:
    rm -rf $(docs_dir)
    $(MAKE) -C docs html
    cp -r docs/_build/html $(docs_dir)
    mv $(docs_dir)/_static $(docs_dir)/static
    mv $(docs_dir)/_sources $(docs_dir)/sources
    perl -pi -e "s/_sources/sources/g;" $(docs_dir)/*.html
    perl -pi -e "s/_static/static/g;" $(docs_dir)/*.html
    git checkout gh-pages
    rm -r sources static
    cp -rf $(docs_dir)/* .
    git add .
    git commit -a -m 'Updates $(project) documentation.'
    git checkout master
    rm -rf $(docs_dir)

Теперь по вызову make ghdocs я обновляю документацию после каждого релиза tddspry, которая теперь и впредь доступна всем ;)

зы. После коммита документацию можно было бы сразу пушить в репо, но иногда не бывает интернета под рукой, иногда очепятку найдешь уже после коммита, посему я потом вручную перехожу на gh-pages и делаю git push origin gh-pages.

Test or die!

2009-04-24T21:40:00.008+03:00

Сегодня я расскажу вам о тестах. Нет, я не буду рассказывать, почему это важно или зачем это нужно делать. Об этом вы прочтете у других авторов. Я же расскажу вам при помощи чего я тестирую свои Django-проекты и приложения.

Итак, знакомтесь, tddspry - альтернатива стандартному подходу в тестировании Django приложений.

Как мы знаем из документации и практики для тестирования приложения надо:

Собственно написать док или юнит-тест. Если это юнит-тест, то разместить его в tests.py или tests/ приложения (при этом надо помнить, что в этом приложении должен присутствовать хотя бы пустой models.py).
Выполнить тесты при помощи ./manage.py test app.

Вроде бы ничего сложного или религиозно неправильного нет. Но, я просто не привык к ним. Не привык и точка. Мне намного проще тестировать приложения при помощи python-nose, а вместо стандартного django.test.Сlient использовать twill-овский браузер.

Не буду вдаваться в подробности почему так произошло, но, поверьте, я рад этому до сих пор. Единственное, что меня не устраивало в последнее время это кое-какая монструозность нашей библиотеки для тестирования (которая tddspry и зовется ;) ). И посему я решил вспомнить и применить на практике значение слова рефакторинг. Прошел процесс быстро и практически безболезнено и за три неплоных дня мы имеем практически, да чего уж там таить, фактически новое лицо для нее.

Итак, что-же сейчас умеет tddspry:

Есть три базовых тест-кейса:
- tddspry.NoseTestCase - этот тест-кейс предназначается для любых тестов и по-большому счету является нашим ответом ~~Чемберлену~~ unittest.TestCase. Его особенности: он содержит все декораторы из nose.tools как статические методы класса, а все прочие функции из того же nose.tools как методы объекта.
- tddspry.django.DatabaseTestCase - этот тест-кейс предназначается для тестов в которых необходимо использовать базу данных. Как и в стандартном поведении unittest.TestCase он создает или просто настраивает для тестов: а) базу данных sqlite3 в оперативной памяти; б) текущую базу данных из settings файла проекта; в) тестовую базу данных. Самым быстрым для тестов является вариант создания sqlite3 базы данных в оперативной памяти и именно он используется по умолчанию. Но никто не говорит, что вы не сможете протестировать любой другой адаптер. Для этого просто укажите database_name аттрибут в вашем тест-кейсе, наследующем DatabaseTestCase. Также, аналогично к джанговским тест-кейсам, DatabaseTestCase умеет загружать фикстуры. И напоследок этот тест-кейс содержит три безумно простых метода для проверки создания, удаления и исправления модели: они же check_create, check_delete, check_update.
- tddspry.django.HttpTestCase - этот тест-кейс предназначается для тестов серверной части вашего Django проекта при помощи twill-браузера. Почему twill? Потому что он простой и он на Python'e ;) Единственным существенным его недостатком считаю отсутствие простой функции для кастомного (не GET-запроса), посему в тестировании POST или PUT запросов вам прийдется дополнительно использовать или джанговский тест-клиент или просто напросто urllib2. Так, но это мы отвлеклись. Что еще особенного в HttpTestCase? Да то, что он содержит в себе все функции из twill.commands, а также кое-какие стоящие хелперы, как то login, login_to_admin, logout, из названия которых становится ясно, что они делают. Также упрощен интерфейс перехода по урлам, в функцию go можна передать как уже чистый урл, так и только имя его урлпаттерна, которое будет сконвертировано в чистый урл при помощи django.core.urlresolvers.reverse.
Есть пару воспомогательных хелперов как-то:
- tddspry.django.helpers.create_profile
- tddspry.django.helpers.create_staff
- tddspry.django.helpers.create_superuser
- tddspry.django.helpers.create_user
из названия которых вроде бы опять становится ясно, что они делают.
Есть крутой воспомогательный хелпер для проверки работы регистрационного механизма django-registration. Он зовется tddspry.django.helpers.registration.registration.
Есть прелесный декоратор show_on_error, который автоматически включен для каждого тестового метода в HttpTestCase. Его прелесть заключается в том, что при ошибке twill'a он показывает содержимое страницы на которой произошла ошибка или при наличии переменной окружения TWILL_ERROR_DIR сохраняет в этой директории html-страницу с ошибкой.

Для установки библиотеки, достаточно просто выполнить sudo easy_install tddspry. А для непосредственного тестирования вашего Джанго-проекта или приложения необходимо присвоить переменной окружения DJANGO_SETTINGS_MODULE значение актуальных настроек и сказать nosetests :)

Для окончательного примера покажу, какой командой тестируется сам tddspry:

PYTHONPATH=/srv/projects/tddspry-github:. DJANGO_SETTINGS_MODULE=testproject.settings nosetests -w .. --with-coverage --cover-package=tddspry --exe testproject

Так что, надеюсь, что моя информация будет вам полезна и вы будете следить за дальнейшим развитием tddspry. Ведь в планах у меня есть поддержка Django 1.1, использование Selenium или Windmill для клиентских тестов и куча прочих полезностей.

зы. Совсем забыл ;) Примеры тестов, написанных при помощи tddspry, вы можете найти где-то здесь.

зыы. Особенная благодарность Almad'у, автору django-sane-testing, за стимул к полному рефакторингу tddspry. Краткое объяснение: он написал мне в личку на гитхабе, мол так и так, я уже сделал практически то же самое только с Селениумом и без Твилла, посмотри может тебе пригодится. Я посмотрел на его тесты и я окончательно понял, что надо улучшать tddspry.

Давайте просто поищем!

2009-04-18T15:44:00.003+03:00

Как Вы, наверное, знаете поиск и Django - понятия весьма и весьма родные. Каких только приложений не написали для этих целей: и djapian, и и solango, и даже haystack. И это все хорошо, и замечательно, но что делать если нужен простой, совсем простой, поиск по сайту без использования дополнительных поисковых движков? Ответ прост: писать свой очередной велосипед. Что я с удовольствием и сделал!

Итак, знакомтесь: kikola.contrib.basicsearch - приложение для легковесного поиска по любым моделям в вашем проекте.

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

Решение:

Добавляем kikola.contrib.basicsearch в INSTALLED_APPS;

Настраиваем SEARCH_MODELS там же, в settings'ах:

SEARCH_MODELS = {
   'flatpages.FlatPage': {
       'description': '{{ obj.content|truncatewords_html:20 }}',
       'fields': ('title', 'content'),
       'priority': 0,
       'title': '{{ obj.title }}',
   },
   'sample.SampleModel': {
       'description': '{{ obj.overview|truncatewords_html:20 }}',
       'fields': ('name', 'slug', 'overview'),
       'priority': 100,
       'trigger': lambda obj: obj.is_active,
   },
}

Добавляем kikola.contrib.basicsearch.urls в ROOT_URLCONF-модуль;
???
Profit!

Иными словами, сейчас запустив тестовый сервер проекта и зайдя на 127.0.0.1:8000/search/ перед нами будет страничка с поисковой формой в которой мы сможем поискать и по всем FlatPage, и по только активным SampleModel.

зы. Код SampleModel:

from django.db import models
from django.db.models import permalink
from django.utils.translation import ugettext_lazy as _


class SampleModel(models.Model):

   name = models.CharField(_('name'), max_length=64)
   slug = models.CharField(_('slug'), max_length=64)
   overview = models.TextField(_('overview'), blank=True)
   is_active = models.BooleanField(_('actived'), blank=True, default=True)

   def __unicode__(self):
       return self.name

   def get_absolute_url(self):
       return ('sample_urlname', [self.slug])
   get_absolute_url = permalink(get_absolute_url)

django-mediafiles 0.2

2009-02-27T01:39:00.003+02:00

Сегодня оффициально вышел первый публичный релиз моего проекта, под названием django-mediafiles.

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

Главная страница

Создание новой директории или файла, загрузка файла на сервер

Удаление директории

Предпросмотр рисунков, кода или редактирование текстовых файлов

Надеюсь, что кому-то этот проект пригодится. Enjoy!

Джанго дб моделс кью - ай лав ю!

2009-02-22T01:43:00.007+02:00

Значится, дано следующий фрагмент models.py:

class Attribute(models.Model):
    ATTRIBUTE_PERMISSIONS = (
        ('public', _('Public')),
        ('semi-private', _('Semi-Private')),
        ('private', _('Private'))
    )

    property_ = models.ForeignKey('Property')
    type_ = models.ForeignKey('AttributeType')
    value = models.CharField(max_length=255)
    permission = models.PositiveIntegerField(choices=ATTRIBUTE_PERMISSIONS,
        default=ATTRIBUTE_PUBLIC)
    granted_users = models.ManyToManyField('auth.User', blank=True, null=True)

class AttributeType(models.Model):
    slug = models.SlugField(max_length=32)
    """
    Other implementation of AttributeType class was stripped
    """

class Property(models.Model):
    owner = models.ForeignKey('auth.User')
    """
    Other implementation of Property class was stripped
    """

Теперь, внимание, задание: надо найти все объекты Property, у которых:

значение публичного аттрибута attr1 равно "Public";
значение полу-приватного аттрибута attr2 равно "Semi-Private";
значение приватного аттрибута attr2 равно "Private".

Казалось бы, как сложно и тут будет много запросо к базе данных, ведь это ж Django, это ж никому не нужный ORM. Вот если бы настрочить большой и сложный SQL, эх. Но, вот именно тут на арену и выходит django.db.models.Q.

Судите сами,

для того чтобы отфильтровать проперти по значению публичного аттрибута, нам надо просто отфильтровать проперти по .filter(attribute_type___slug='attr1', attribute__permission='public', attribute__value='Public')
для фильтра по значению полу-приватного аттрибута, надо дополнительно ввести фильтр проверки на вхождение пользователя в список разрешенных пользователей или этот пользователь является автором проперти: .filter(attribute_type___slug='attr2', attribute__permission='semi-private', attribute__value='Semi-Private', attribute__granted_users=USER).filter(attribute_type___slug='attr2', attribute__permission='semi-private', attribute__value='Semi-Private', owner=USER)
для фильтра же по значению приватного аттрибута, мы просто оставляем вторую часть предыдущего фильтра: .filter(attribute_type___slug='attr2', attribute__permission='private', attribute__value='Private', owner=USER)

Как-то слишком монструозно выходит, просто фильтровать. Давайте, лучше создадим хелпер, который будет учитывать особенности всех этих фильтров, проще говоря склеим все фильтры воедино при помощи Q. А затем просто будем фильтровать проперти по названию аттрибута и его значению:

def filter_by_attribute(queryset, **kwargs):
    # Public attributes filter
    basequery = Q(attribute__permission='public')

    if 'user' in kwargs:
        user = kwargs.pop('user')

        # Semi-private attributes filter
        basequery |= Q(attribute__permission='semi-private') & \
                     Q(Q(attribute__granted_users=user) | \
                       Q(owner=user))

        # Private attributes filter
        basequery |= Q(attribute__permission='private') & Q(owner=user)

    for slug, value in kwargs.items():
        query = basequery & \
                Q(attribute__type___slug=slug) & \
                Q(attribute__value=value)

        queryset = queryset.filter(query)

    return queryset

queryset = Property.objects.all()
queryset = filter_by_attribute(queryset, attr1='Public', attr2='Semi-Private', user=USER)
queryset = filter_by_attribute(queryset, attr2='Private', user=USER)

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

зы. Я знаю, что filter_by_attribute лучше было бы прицепить к кастомному PropertyManager'у, но это выходит за рамки моей сегодняшней темы ;)

Перевод строки в Boolean-тип в Python

2009-02-20T04:22:00.004+02:00

Все гениальное просто, а премудростями, описанными в сабже, в Python занимается distutils.util.strtobool. Примеры использования данной функции настолько тривиальны, что я ограничусь уже вышесказанным ;)

зы. Давно уже присматривался к Posterous и вот наконец-то созрел для того, чтобы попробовать. Отныне на этом блоге будут хранится подобные советы, связанные в основном с Питоном и Джанго.

Полезные функции в Django

2009-02-16T00:57:00.007+02:00

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

django.utils.datastructures.SortedDict

django.utils.datastructures.MultiValueDict

По умолчанию в Python объект dict не поддерживает сортировку ключей и несколько значений для одного ключа. Именно поддержку этих возможностей дают перечисленные выше классы. Например, поддержка GET, POST, REQUEST массивов в объекте request реализована в виде MultiValueDict объектов.

django.utils.dates

Этот модуль содержит разнообразные массивы, которые используются для печати SelectDateWidget'а.

django.utils.encoding.force_unicode

Переводит любой Python объект в unicode. Так же переводит в unicode любую модель Django у которой есть метод __unicode__.

django.utils.html.clean_html

Очищает переданный в функцию HTML строку, а именно:

Конвертирует  и  в  и .
Правильно кодирует все амперсанды.
Удаляет все "target" аттрибуты с тегов <a>.
Конвертирует явно заданные баллетсы (bullets) в неупорядоченные HTML списки.
Удаляет из текста фрагменты "  ", но только если они находятся в конце текста.

django.utils.html.urlize

Переводит все ссылки в тексте в <a> тэги.

django.utils.safestring.mark_safe

Обозначает любой строковой объект, как безопасный для того, чтобы он мог был беспрепятственно распечатан в шаблоне без эскейпинга символов.

django.utils.text.get_text_list

Для описания работы этой функции и doctest'а хватит:

>>> get_text_list(['a', 'b', 'c', 'd'])
u'a, b, c or d'
>>> get_text_list(['a', 'b', 'c'], 'and')
u'a, b and c'
>>> get_text_list(['a', 'b'], 'and')
u'a and b'
>>> get_text_list(['a'])
u'a'
>>> get_text_list([])
u''

Надеюсь, что Вам пригодится что-то из моего списка.

Простой и работающий JSONField для Django

2009-02-13T02:56:00.004+02:00

Не успел, я починить PickleField для Django, мне понадобилось создать JSONField. Задача оказалась решенной на раз/два, плюс ко всему добавился маленький и полезный виджет для JSONField'а, который показывает красиво отформатированный JSON в textarea. Сразу скажу, что contribute_to_class метод чуть менне, чем полностью, скопипастен с снипетта 377.

from django.conf import settings
from django.forms.widgets import Textarea
from django.db.models import SubfieldBase, TextField
from django.utils import simplejson


class JSONField(TextField):
    __metaclass__ = SubfieldBase

    def contribute_to_class(self, cls, name):
        super(JSONField, self).contribute_to_class(cls, name)

        def get_json(model):
            return self.get_db_prep_value(getattr(model, self.attname))
        setattr(cls, 'get_%s_json' % self.name, get_json)

        def set_json(model, json):
            setattr(model, self.attname, self.to_python(json))
        setattr(cls, 'set_%s_json' % self.name, set_json)

    def formfield(self, **kwargs):
        kwargs['widget'] = JSONWidget(attrs={'class': 'vLargeTextField'})
        return super(JSONField, self).formfield(**kwargs)

    def get_db_prep_value(self, value):
        return simplejson.dumps(value)

    def to_python(self, value):
        if not isinstance(value, basestring):
            return value

        try:
            return simplejson.loads(value, encoding=settings.DEFAULT_CHARSET)
        except ValueError, e:
            # If string could not parse as JSON it's means that it's Python
            # string saved to JSONField.
            return value

class JSONWidget(Textarea):
    """
    Prettify dumps of all non-string JSON data.
    """
    def render(self, name, value, attrs=None):
        if not isinstance(value, basestring) and value is not None:
            value = simplejson.dumps(value, indent=4, sort_keys=True)
        return super(JSONWidget, self).render(name, value, attrs)

Ну и пару примеров использования, напоследок:

>>> # Пусть у нас есть простая модель
>>> class Sample(models.Model):
...    name = models.CharField(max_length=16)
...    data = JSONField()

>>> # Создадим модель и сохраним в data поле настройки для ShadowBox
>>> sb = Sample.objects.create(name='ShadowBox',
...                            data={'autoDimensions': True,
...                                  'overlayOpacity': 0.5,
...                                  'skipSetup': True})

>>> # Теперь мы хотим напечатать эти настройки где-то в шаблоне
>>> sb.get_data_json()
'{"overlayOpacity": 0.5, "autoDimensions": true, "skipSetup": true}'

>>> # Вспомним, что нам вообщем-то не зачем кастомное значение для overlayOpacity
>>> del sb.data['overlayOpacity']
>>> sb.save()

>>> # И опять напечатаем настройки в шаблоне
>>> sb.get_data_json()
'{"autoDimensions": true, "skipSetup": true}'

зы. ShadowBox - это лучший лайтбокс для любого JavaScript фреймворка, имо.

По-настоящему, рабочий Django PickleField

2009-02-13T02:32:00.001+02:00

Важнее некуда: В PickleField добавлена возможность полноценного хранения объектов моделей и поддержка питоновских значений по умолчанию.

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

Иногда возникает необходимость хранить какие-то данные, "сериализированные" с помощью pickle или cPickle, в базе данных. Для этих случаев весьма кстати будет PickleField. Вообщем, может быть кому-то пригодится.

from django.conf import settings
from django.db import models

if getattr(settings, 'USE_CPICKLE', False):
    import cPickle as pickle
else:
    import pickle

class PickleField(models.TextField):
    __metaclass__ = models.SubfieldBase

    editable = False
    serialize = False

    def get_db_prep_value(self, value):
        return pickle.dumps(value)

    def to_python(self, value):
        if not isinstance(value, basestring):
            return value

        # Tries to convert unicode objects to string, cause loads pickle from
        # unicode excepts ugly ``KeyError: '\x00'``.
        #
        # If not possible, return this value, cause it's not pickled yet.
        if isinstance(value, unicode):
            try:
                str_value = str(value)
            except UnicodeEncodeError:
                return value
        else:
            str_value = value

        try:
            return pickle.loads(str_value)
        except ValueError:
            # If pickle could not loads from string it's means that it's Python
            # string saved to PickleField.
            return value

Также добавил простейший тест для показания работы PickleField'a:

import unittest

from django.db import models

from fields import PickleField

class PickleObject(models.Model):
    name = models.CharField(max_length=16)
    data = PickleField()

class TestPickleField(unittest.TestCase):
    def setUp(self):
        PickleObject.objects.all().delete()

    def test_not_string_data(self):
        items = [
            'Item 1', 'Item 2', 'Item 3', 'Item 4', 'Item 5'
        ]

        obj = PickleObject.objects.create(name='default', data=items)
        self.assertEqual(PickleObject.objects.count(), 1)

        self.assertEqual(obj.data, items)

        obj = PickleObject.objects.get(name='default')
        self.assertEqual(obj.data, items)

    def test_string_and_unicode_data(self):
        DATA = (
            ('string', 'Simple string'),
            ('unicode', u'Simple unicode string'),
        )

        for name, data in DATA:
            obj = PickleObject.objects.create(name=name, data=data)
            self.assertEqual(obj.data, data)

        self.assertEqual(PickleObject.objects.count(), 2)

        for name, data in DATA:
            obj = PickleObject.objects.get(name=name)
            self.assertEqual(obj.data, data)

Надеюсь, что в скором времени эти изменения будут добавлены в django-fields.

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

2008-10-09T00:44:00.006+03:00

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

Итак, работая с любым Django проектом я использую целую тучу разнообразнейших reusable apps. Установка и добавления любого reusable app'а в свой Django-проект проста и не тривиальна: клонирование репозитория, обновление sys.path, добавление appname в INSTALLED_APPS.

Намного интересней становится, когда приходит время пробежаться по всем склонированным локально репозиториям и проверить наличие обновление в них (сейчас и далее актуально только для тех, кто на передовой). Согласитесь, имея в наличии под 100 svn репозиториев c googlecode, да 20-30 git репозиториев с github'а, а также по паре тройке разнообразных bzr с hg репозиториев, их обновление посредством ручного набора поочередно:

$ svn up /path/to/django
$ cd /path/to/werkezeug && hg fetch
$ cd /path/to/django-debug-toolbar && git pull

будет очень и очень надоедливо. И именно по-этому, я быстро на коленке написал простой скрипт для обновления всех склонированных репозиториев в текущем или указанном каталоге. Код скрипта, ниже. Сразу предупреждаю, за именование переменных, а также использование os.system, не ругать, так как в час ночи не до жиру ;)

#!/usr/bin/env python

import os, sys

def run():
    if len(sys.argv) == 2:
        dirname = os.path.expanduser(sys.argv[1])
    else:
        dirname = os.getcwd()

    if not os.path.isdir(dirname):
        sys.stderr.write('Directory "%s" was not exists or you ' % dirname + \
                         'have not permissions to read from it.\n')
        sys.exit(1)

    dirdata = os.listdir(dirname)

    not_scms = []
    scms = (
        ('bzr', []),
        ('git', []),
        ('git-svn', []),
        ('hg', []),
        ('svn', []),
    )

    dirs_len = len(dirdata)
    scms_len = 0

    for name in dirdata:
        subdirname = os.path.join(dirname, name)

        if not os.path.isdir(subdirname):
            continue

        scms_len += 1
        subdirdata = os.listdir(subdirname)

        if '.bzr' in subdirdata:
            scms[0][1].append(subdirname)
        elif '.git' in subdirdata:
            f = open(os.path.join(subdirname, '.git/config'), 'r')
            if not 'svn-remote' in f.read():
                scms[1][1].append(subdirname)
            else:
                scms[2][1].append(subdirname)
            f.close()
        elif '.hg' in subdirdata:
            scms[3][1].append(subdirname)
        elif '.svn' in subdirdata:
            scms[4][1].append(subdirname)
        else:
            scms_len -= 1
            not_scms.append(subdirname)

    print 'Work directory:', dirname
    print 'Number of found subdirs:', dirs_len
    print 'Number of found SCM dirs:', scms_len

    if dirs_len != scms_len:
        print 'Not SCM dirs:', not_scms

    print

    if not scms_len:
        sys.exit(0)

    for protocol, dirs in scms:
        if protocol == 'bzr':
            cmd = "cd '%s' && bzr pull"
        elif protocol == 'git':
            cmd = "cd '%s' && git pull"
        elif protocol == 'git-svn':
            cmd = "cd '%s' && git svn fetch"
        elif protocol == 'hg':
            cmd = "cd '%s' && hg fetch"
        elif protocol == 'svn':
            cmd = "svn update '%s'"

        dirs.sort()

        for d in dirs:
            print '$', cmd % d
            os.system(cmd % d)
            print

if __name__ == '__main__':
    run()

Теперь вы можете сохранить этот код в любой файл (я, например, использую название scm-up-all.py) и поместить этот файл в PATH. Таким образом обновление всех репозиториев в /srv/shared стало плевым делом ;)

UPD: На днях появилось желание чуточку проапдейтить скрипт, потому я решил завести для него проект на GitHub. В ToDo: поддержка CVS, Darcs; вывод информации о последнем коммите (последней ревизии) в репозитории; простой GUI (PyQt4) для управления обновлением.

Django 1.0 was released

2008-09-04T08:36:00.004+03:00

Примите мои самые искренние поздравления, друзья, в связи с этой отличнейшей новостью :)

Ну это просто праздник какой-то!

2008-07-19T10:38:00.004+03:00

Django's newforms-admin branch merged into trunk

Лирическое отступление: Знаете, меня сейчас переполняют настолько положительные эмоции, что их просто невозможно как-то точно сформулировать и/или описать.

Но если по сути, то бранч newforms-admin уже давно заслужил быть слитым в транк. Почему?

Потому что, кастомизация административной панели Django переходит на совершенно новый уровень.
Потому что, один сайт != одна административная панель Джанго.
Потому что, class Media для форм! И теперь для добавления кастомного CSS или JavaScript не надо реализовывать свой велосипед.
Потому что, формсеты.
Да и просто потому что, oldforms – это уже история.

И что самое главное, каких-то экстра трудностей по переходу на newforms-admin наблюдаться не должно. А если еще не использовал в проектах встроенную админку – то их вообще не будет ;)

upd. Не так много времени прошло после мерджинга newforms-admin в trunk, как была выпущена первая альфа 1.0 релиза Django, и вместе с тем библиотека django.newforms тоже стала историей ;) Отныне есть только The forms library.

Fixed #2070: refactored Django's file upload capabilities.

2008-07-01T19:56:00.005+03:00

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

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

зы. И да, newforms-admin уже тоже поддерживает эту фишку ;)

Поддержка поля "Запомнить меня" в формах авторизации в Django

2008-06-10T01:06:00.006+03:00

Замечательнейший changeset номер 7586 теперь позволяет реализовать описанный в сабже функционал прямо в методе save() формы авторизации:

from django import newforms as forms
from django.contrib import auth

class LoginForm(forms.Form):
    username = forms.CharField(...)
    password = forms.CharField(...)
    remember_me = forms.BooleanField(...)

    user_cache = None

    ...

    def save(self, request):
        cd = self.cleaned_data
        user = self.user_cache

        auth.login(request, user)

        if not 'remember_me' in cd or not cd['remember_me']:
            request.session.set_expire(0)

        return user

Вот и не используй после этого Django из транка.

зы. Документация по сессиям в Django

Django Forum - это реально

2008-05-30T13:47:00.007+03:00

Конечно, я знаю, что для Django есть десятки прототипов решений форума, начиная от Cicero и заканчивая Snapboard и Mighty Board. Но не с одним из этих прототипов мне не удалось подружиться быстро и безболезненно. Всегда надо было предпринимать какие-то лишние телодвижения, связанные с пониманием идеологии того или иного форума.

И вот вчера, когда я еще раз просматривал списки доступных решений я наткнулся на статью ForumAppsComparsion в Django Code Wiki. Присмотрелся я к табличке и понял, что не имел дело всего лишь с django-threadedcomments и Django Forum. Благо и одно и второе приложение содержало демо-версии и я решил остановится на них подробней.

django-threadedcomments я сразу отбросил из-за названия и области применения (и даже прикольная демка не спасла его :)).

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

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

Ну а напоследок, как всегда пачка скриншотов, в этот раз для тех кому лень идти на демонстрцию :)

Главная страница моего форума (уже частично локализированного)
Список тем в форуме
Отображение темы
Добавить новое сообщение в тему
Отображение профиля

зы. Позволю себе еще одно замечание. Если вы хотите использовать этот форум в STANDALONE режиме - не забудьте папки css, img и js в media/ перенести в media/forum/. А то после django-manage.py runserver Вы вполне можете не увидеть ни стилей, ни рисунков, ни смайлов. А только текст, один текст.

jQuery AutocompleteWidget для Django

2008-05-29T20:14:00.020+03:00

По моему скромному мнению, сейчас найти правильный сниппет, показывающий как реализовать автозаполнение на том или ином языке программирования с использованием того или иного JavaScript фреймворка - пустяковое дело.

Так что будем считать, что сегодня просто сама по себе настала очередь связки jQuery + Django. Реализация виджета автозаполнения в этой связке - проста до ужаса. Особенно, когда используется великолепный jQuery Autocomplete plugin.

Вся идея реализации состоит в следующем:

Определяем какие данные будут использоваться в автозаполнении (локальные или удаленные)
Если данные удаленные, пишем view и добавляем этот view в urlpatterns
Получаем автозаполняемое поле

Но чтобы потом в дальнейшем по сто раз не дописывать этот виджет я чуточку его модифицировал. И посему Вы можете указать какие поля являются зависимыми от текущего (это например, очень полезно в связке страна - город, ведь незачем выбрав страну Украина, автодополнять город Амстердам). Это раз, а два - Вы можете указать какие именно опции плагина вам необходимы для этого поля.

Ну что ж, перейдем к программному коду. Для начала сам виджет:

from django.core.urlresolvers import reverse, NoReverseMatch
from django.newforms import HiddenInput, TextInput
from django.utils import simplejson
from django.utils.safestring import mark_safe

class AutocompleteWidget(TextInput):
    """
    Autocomplete widget to use with jquery-autocomplete plugin.

    Widget can use for static and dynamic (AJAX-liked) data. Also
    you can relate some fields and it's values'll posted to autocomplete
    view.

    Widget support all jquery-autocomplete options that dumped to JavaScript
    via django.utils.simplejson.

    **Note** You must init one of ``choices`` or ``choices_url`` attribute.
    Else widget raises TypeError when rendering.
    """
    def __init__(self, attrs=None, choices=None, choices_url=None, options=None, related_fields=None):
        """
        Optional arguments:
        -------------------

            * ``choices`` - Static autocomplete choices (similar to choices
            used in Select widget).

            * ``choices_url`` - Path to autocomplete view or autocomplete
            url name.

            * ``options`` - jQuery autocomplete plugin options. Auto dumped
            to JavaScript via SimpleJSON

            * ``related_fields`` - Fields that relates to current (value
            of this field will sended to autocomplete view via POST)
        """
        self.attrs = attrs or {}
        self.choice, self.choices, self.choices_url = None, choices, choices_url
        self.options = options or {}

        if related_fields:
            extra = {}
            if isinstance(related_fields, str):
                related_fields = list(related_fields)

            for field in related_fields:
                extra[field] = "%s_value" % field

            self.extra = extra
        else:
            self.extra = {}

    def render(self, name, value=None, attrs=None):
        if not self.choices and not self.choices_url:
            raise TypeError('One of "choices" or "choices_url" keyword argument must be supplied obligatory.')

        if self.choices and self.choices_url:
            raise TypeError('Only one of "choices" or "choices_url" keyword argument can be supplied.')

        choices = ''

        if self.choices:
            self.set_current_choice(value)
            choices = simplejson.dumps([unicode(v) for k, v in self.choices], ensure_ascii=False)
            html_code = HiddenInput().render(name, value=value)
            name += '_autocomplete'
        else:
            html_code = ''

        if self.choices_url:
            try:
                choices = simplejson.dumps(reverse(str(self.choices_url)))
            except NoReverseMatch:
                choices = simplejson.dumps(self.choices_url)

        if self.options or self.extra:
            if 'extraParams' in self.options:
                self.options['extraParams'].update(self.extra)
            else:
                self.options['extraParams'] = self.extra

            options = ', ' + simplejson.dumps(self.options, indent=4, sort_keys=True)
            extra = []

            for k, v in self.extra.items():
                options = options.replace(simplejson.dumps(v), v)
                extra.append(u"function %s() { return $('#id_%s').val(); }\n" % (v, k))

            extra = u''.join(extra)
        else:
            extra, options = '', ''

        final_attrs = self.build_attrs(attrs)
        html_code += super(AutocompleteWidget, self).render(name, self.choice or value, attrs)

        html_code += u"""
<script type="text/javascript"><!--
    %s$('#%s').autocomplete(%s%s);
--></script>
""" % (extra, final_attrs['id'], choices, options)

        return mark_safe(html_code)

    def set_current_choice(self, data):
        if not self.choices:
            raise ValueError('"choices" attribute was not defined yet.')

        for k, v in self.choices:
            if k == data:
                self.choice = v
                break

    def value_from_datadict(self, data, files, name):
        if not self.choices:
            return super(AutocompleteWidget, self).value_from_datadict(data, files, name)

        autocomplete_name = name + '_autocomplete'

        if not autocomplete_name in data:
            self.set_current_choice(data[name])
            return data[name]

        for k, v in self.choices:
            if v == data[autocomplete_name]:
                self.set_current_choice(k)
                return k

Теперь примеры его использования:

forms.py
from django import newforms as forms
from django.utils.translation import ugettext as _

from myproject.widgets import AutocompleteWidget

SPORTS_CHOICES = (
    ('basketball', _('Basketball')),
    ('football', _('Football')),
    ('hockey', _('Hockey')),
)

class SampleForm(forms.Form):
    name = forms.CharField(label=_('Name'))
    country = forms.CharField(label=_('Country'),
        widget=AutocompleteWidget(choices_url='autocomplete_countries', related_fields=('city',)))
    city = forms.CharField(label=_('City),
        widget=AutocompleteWidget(choices_url='autocomplete_cities', related_fields=('country',)))
    sports = forms.ChoiceField(label=_('Sports'), choices=SPORTS_CHOICES,
        widget=AutocompleteWidget(options={'minChars': 0, 'autoFill': True, 'mustMatch': True}))

urls.py
from django.conf.urls.defaults import *

urlpatterns = patterns('',
    url('/path/to/cities/autocomplete/', 'views.autocomplete_cities', name='autocomplete_cities'),
    url('/path/to/countries/autocomplete/', 'views.autocomplete_countries', name='autocomplete_countries'),
)

views.py
from myproject.models import City

def autocomplete_cities(request):
    def results_to_string(results):
        if results:
            for r in results:
                yield '%s|%s\n' % (r.name, r.pk)

    city = request.REQUEST.get('q', None)
    country = request.REQUEST.get('country', None)

    if city:
        cities = City.objects.filter(city__istartswith=city)
    else:
        cities = City.objects.all()

    if country:
        cities = cities.filter(country__name=country)

    cities = cities[:int(request.REQUEST.get('limit', 15))]
    return results_to_string(cities, mimetype='text/plain')

А вот как это выглядит ВРЛ:

Автозаполнение поля "City" (удаленные данные)
Автозаполнение поля "Country" (удаленные данные)
Связь при автозаполнении между полями "Country" и "Сity"
Автозаполнение поля "Sports" (локальные данные)

За сим прощаюсь и поздравляю всех с наступающим долгожданным летом!

Расширение функционала django-admin.py и django-manage.py с помощью django-command-extensions

2008-05-29T20:14:00.017+03:00

Вообще, утилиты командной строки django-admin.py и django-manage.py обладают кучей полезных и крайне юзабельных функций (dbshell, runserver, shell и тп), но иногда и их бывает недостаточно.

И именно тогда на помощь приходит django-command-extensions! Это приложение расширяет стандартные возможности утилит Django и теперь вы можете:

Создавать скелет приложения по своему шаблону (create_app)
Создавать скелет для своей комманды (create_command)
Быстро добавлять суперпользователя в базу данных (create_superuser)
Быстро создать форму для необходимой модели (describe_form)
Создать базу контактов пользователей вашего проекта (export_email)
Сгенерировать SECRET_KEY для настроек проекта (generate_secret_key)
Создать граф, показывающий связь между моделями (graphviz)
Сбросить пользовательский пароль (passwd)
Использовать python shell с автоматически загруженными классами всех моделей проекта (shell_plus)
Просмотреть все существующие в проекте urlpatterns (show_urls)
Показать разницу между определением модели и тем, что присутствует в базе данных (sqldiff)
Создать и запустить определенное задание (create_job, run_job, run_jobs)

Остается только поблагадорить разработчиков приложения и перейти к его скачиванию/установке/использованию.

Ссылки:

django-manage.py или не единым django-admin.py сыты будем

2008-05-14T19:19:00.008+03:00

В разработке своих проектов на Django я придерживаюсь архитектуры, близкой к той, которую описал Мальколм Трединник в своей статье "Django Tip: Developing Without Projects". Странно звучит, да, разработка проектов используя методику разработки без проектов.

Но это только на первый взгляд. В действительности я не использую терминологию Django, в которой проект - это продукт действия django-admin.py startproject, порождающий дополнительную ветвь в иерархии и приводящий к повсеместному использованию projectname. в питон коде. Для меня проект - это скорее объединение приложений, как reusable (как-то django-tagging, django-mptt и многие многие другие) с одной стороны, так и тех, которые разрабатываются исключительно для текущего веб-сайта, под одной общей крышей (settings.py, urls.py).

В идеале архитектура любого моего проекта выглядит как:

project/
    application/
    another_application/
    locale/
    templates/
    settings.py
    urls.py

Т.е. по-большому счету ничего лишнего. Управление и деплоймент проекта ведется при помощи универсальной утилиты django-admin.py, которой передаются переменные DJANGO_SETTINGS_MODULE (settings) и PYTHONPATH (абсолютный путь к project/) (опять же в идеале создаются алиасы для каждого из проекта вида django-project и это в дальнейшем облегчает их использование в коммандной строке).

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

$ ./manage.py synccompress

Я, конечно, ничуть не смутился и попытался было:

$ django-project synccompress

но эта попытка закончилась

Unknown command: 'synccompress'
Type 'django-admin.py help' for usage.

Причина оказалось простой и, наверное, вполне логичной. django-admin.py вызывает django.core.management.execute_from_command_line, manage.py же, лежащий в директории проекта, после его создания (startproject), вызывает django.core.management.execute_manager. Вся же разница состоит в том, какая утилита управления (ManagementUtility) инициализируется и выполняется в этих функциях. И в итоге, ProjectManagementUtility считывает дополнительные команды, которые находятся в директории commands всех приложений, перечисленных в INSTALLED_APPS проекта. Именно это и дает возможность выполнения кастомных команд.

Собственно все это и навело на мысль создания "магичной" (новый тренд в джанго-среде) утилиты django-manage.py. Программный код этого велосипеда:

#!/usr/bin/env python

import os, sys

if __name__ == '__main__':
    try:
        dirname = os.environ['PWD']
    except KeyError:
        import subprocess
        dirname = subprocess.Popen('cd', shell=True, stdout=subprocess.PIPE).communicate()[0].strip()
    sys.path.append(dirname)

    try:
        settings = 'settings'
        try:
            __import__(settings)
        except ImportError, e:
            settings = os.path.basename(dirname) + '.settings'
            __import__(settings)
    except ImportError, e:
        sys.stderr.write("Error: Can't find the file 'settings.py' in the current work directory %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % dirname)
        sys.exit(1)

    os.environ['DJANGO_SETTINGS_MODULE'] = settings
    from django.core import management
    utility = management.ProjectManagementUtility(None, os.path.basename(dirname))
    utility.execute()

Установка выполняется копированием сохраненного кода в PATH и выдачей ему прав на исполнение (последнее только для Unix'ов).

Примеры использования тоже вполне очевидны:

$ cd /path/to/project
$ django-manage.py help
django-manage.py  [options] [args]
Django command line tool, version 0.97-pre-SVN-unknown
Type 'django-manage.py help ' for help on a specific subcommand.
Available subcommands:
  adminindex
  createcachetable
  dbshell
  diffsettings
  dumpdata
  flush
  inspectdb
  loaddata
  reset
  runfcgi
  runserver
  shell
  sql
  sqlall
  sqlclear
  sqlcustom
  sqlflush
  sqlindexes
  sqlinitialdata
  sqlreset
  sqlsequencereset
  startapp
  synccompress
  syncdb
  test
  testserver
  validate

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

Важно! Сей метод подходит лишь для архитектуры, описанной мной в начале поста, если вы используете архитектуру Django-проектов используйте для этих же целей manage.py, расположенный в корне директории проекта.

UPD 1 Добавлена проверка текущей рабочей директории для Windows, так как в нем нет ключа PWD в словаре os.environ.

UPD 2 Добавлена поддержка settings, project.settings (стандартной архитектуры проектов Django).

Django security fix released

2008-05-14T14:35:00.005+03:00

Как сегодня сообщил оффициальный блог разработчиков Django, до недавнего времени в форме входа в админ-панель существовала потенциальная дыра безопасности. И именно поэтому они предоставили обновления для транка (ревизия 7521), версий 0.96 (0.96.2), 0.95 (0.95.3) и 0.91 (0.91.2) и попросили быстрейшим образом обновиться ;)

Больше об этом security fix'е вы можете прочитать на упомянутом выше блоге.