Первая реализация постинга

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

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

Еще по просьбам в комментариях буду выкладывать ссылки на архивы текущих версий для тех, у кого порты Subversion закрыты.

Кто будет ставить себе не забудьте вызвать ./manage.py syncdb, а также прописать в список middleware "cicero.middleware.ProfileMiddleware" (подробности — в статье).

Автор статьи

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

def author_display(self):
  return self.author or self.guest_name

А вот со ссылкой на пользователя все не так просто. Самое очевидное решение — NULL'овое поле author — на самом деле нарушает известный паттерн "Null object". Паттерн этот рекомендует в местах, где встречаются всякие "nobody", "default" и прочие "undefined" вместо тупого NULL'а использовать объект, который реализует поведение по умолчанию. Смысл этого состоит в том, что пропадает нужда везде по коду делать специальные проверки на NULL, что уменьшает сложность системы.

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

Но поскольку пользователи в запрос подцепляются обычным join'ом, то статьи, у которых пользователя нет, не выведутся вообще. Join'а с включением NULL'ов на места отсутствующих записей в Django не реализовано. И поэтому, чтобы не терять записи, Django просто напрочь отключает select_related, если у модели допустимы NULL'овые ForeignKey-ссылки. Можно, конечно, обидеться за это на Django, но это как раз то, что обычно случается со всякими "специальными случаями": они всегда реализуются уже когда-нибудь потом.

Поэтому вместо обNULLения поля "author" я сделал отдельного пользователя с логином "cicero_guest", который будет проставляться для неавторизованных пользователей. Это, соответственно, позволяет использовать select_related для вывода статей. И чтобы это происходило всегда, я включил его в виде менеджера модели:

class ArticleManager(models.Manager):
  def get_query_set(self):
    return super(ArticleManager, self).get_query_set().select_related()

class Article(models.Model):
  # ...
  author = models.ForeignKey(User)

  objects = ArticleManager()

Ну и последний штрих — автоматическое создание этого гостевого юзера при установке приложения. Обычно это делается через написание в нужном месте SQL-скрипта с INSERT'ом, который автоматически выполняется при создании в базе таблиц моделей. Но тут трудность в том, что модель пользователя не моя, а джанговская, а SQL можно писать только для своих моделей.

Поэтому пришлось воспольоваться другим средством. При инициализации приложения Джанго импортирует модуль management.py, который находится в директории приложения. В нем можно подключиться к сигналу "post_syncdb", который запускается как раз после инициализации, и там сделать все что надо:

from django.dispatch import dispatcher
from django.db.models import signals

def init(signal, sender, app, created_models):
  import cicero.models
  if app == cicero.models:
    from django.contrib.auth.models import User
    try:
      cicero_guest = User.objects.get(username='cicero_guest')
    except User.DoesNotExist:
      password = User.objects.make_random_password()
      cicero_guest = User.objects.create_user('cicero_guest', 'cicero_guest@localhost', password)

dispatcher.connect(init, signal=signals.post_syncdb)

Профайл

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

В частности, Cicero нужно для каждого пользователя хранить его выбранный фильтр статей. Куда его вписывать?

Пока я проблему решил так. Я не использую стандартное джанговское понятие профайла вообще. Вместо этого в Cicero появляется еще одна модель собственного профайла:

class Profile(models.Model):
  user = models.OneToOneField(User, related_name='cicero_profile')
  filter = models.CharField(maxlength=50)

  def __init__(self, *args, **kwargs):
    super(Profile, self).__init__(*args, **kwargs)
    self.filter = 'bbcode' # implement reading default from available filters

Соответственно, у юзеров в системе появляется атрибут "cicero_profile", на наличие которого приложение уже может рассчитывать.

В связи с этим вопрос к аудитории. Есть предложения, как решить задачку лучше? Или и так нормально?

Есть, правда, еще одна кривость. При заведении в системе новых пользователей, никто автомагически не будет для них создавать записи Profile'ов, и обращение user.cicero_profile будет вызывать exception. Поэтому, надо их где-то создавать. Я для этого использую middleware, которое вешается где-нибудь после авторизации и для каждого пользователя, залогиненного на сайт, смотрит, есть ли у него профиль, и создает если надо. Минусов я вижу два:

• надо помнить о том, что при установке Cicero надо обязательно включать это middleware
• любой залогиненный пользователь всегда дергает базу лишним запросом

Поэтому у меня есть идея, как это переписать с помощью умных дескрипторов, но это как-нибудь потом...

Формы постинга

Пока в приложении есть место всего для двух форм — создания топика и статьи. Обе они, к сожалению, очень "специальные", не соответствуют напрямую моделям топика и статьи, поэтому их нельзя создать автоматически. Но с другой стороны, они обе страшно маленькие, поэтому файлик forms.py, в который я их вынес, получился компактным:

from django.newforms import *

class ArticleForm(Form):
  text = CharField(label='Текст', required=True, widget=Textarea(attrs={'cols': '80', 'rows': '20'}))
  name = CharField(label='Имя', required=True)

class TopicForm(Form):
  subject = CharField(label='Тема', required=True)
  text = CharField(label='Текст', required=True, widget=Textarea(attrs={'cols': '80', 'rows': '20'}))
  name = CharField(label='Имя', required=True)

Поле "name" по задумке будет принимать либо произвольное имя гостя, либо в будущем — OpenID'шный URL. А для уже залогиненных пользователей показываться не будет вообще.

Две view-функции, обрабатывающие формы, очень похожи: одной надо создать топик и первую статью с автором, второй — только статью с автором. Сам скелет функций совершенно стандартен для обработки форм, привожу его исключительно "для порядку" :-)

# передать POST в форму
form = TopicForm(request.POST) # или ArticleForm

if not form.is_valid():
  # если ошибки, выдать ответ с формой и ошибками
  return render_to_response(... {'form': form})

# если же все хорошо, сохранить отвалидированные данные
_create_article(topic, form, request.user)

# вернуться на URL, откуда пришли  
return HttpResponseRedirect('../')

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

Поэтому я сейчас сделал отдельные шаблоны, где есть только форма добавления, и при ошибках вывожу их. То есть, человек, который ошибается при попытке постинга перебрасывается на отдельную страницу с формой ввода. Кривовато :-). Единственное, что меня успокаивает в этом варианте, что он практически не будет никогда работать: я повешу на формы постинг ajax'ом, и там надо будет возвращать только словарик с ошибками, а не всю страницу заново.

Впрочем, вот прямо сейчас у меня созрела и другая мысль. Действительно перетащить код добавления топика и статьи в view-функции вывода списка топиков и списка статей. Это во-первых устранит нужду в отдельных шаблонах, а во-вторых будет совпадать по идеологии с Atom Publishing Protocol, который я в конце собираюсь навешивать... Здраво?

В итоге, я вывесил эту уже минимально работающую версию на http://softwaremaniacs.org/cicero/. Она, конечно, экстремально страшная, но пусть будет. В следующий раз займусь как раз приведением в порядок шаблонов.