Как стать автором
Обновить

Комментарии 53

Спасибо за полезную статью, жалко что django мало освещен в рунете
НЛО прилетело и опубликовало эту надпись здесь
Ну не так уж и мало. Есть отличный форум Ивана Салагаева, блог Александра Кошелева, русские google-groups, djbook, pydev.ru, русский py-агреггатор… А в аглицком и-нете вообще всего полно.
НЛО прилетело и опубликовало эту надпись здесь
Да, помирает… Ухи просит. Сам давно не ходул туда — просто в закладках лежит ;-)
Пожалуйста, пишите правильно мою фамилию — Сагалаев.
Иван, извините, пожалуйста — торопился и буквы перепутались. Впредь буду аккуратнее.
Да ваш блог, даже скорее форум, единственное место где можно найти хоть какие то ответы на множество вопросов
О, вы на Хабре, я и не знал :) Жаль, что стали мало писать в блог про технические штуки джанговские, всегда интересно почитать было.
Иван, спасибо за наверное лучший доклад на киевской конференции. Хоть это было давно, но заряд энтузиазма еще держится. Приезжайте еще, с чем нибудь новым и таким же интересным.
Спасибо за подборку ссылок, буду знать, что читать.
НЛО прилетело и опубликовало эту надпись здесь
Имхо только у Ивана и можно что-то найти все остальные форумы/сайты на стадии мертв
Да, хорошее приложение.
Но я его поздно нашел, и по сути написал свое такое же в проекте. Но с учетом продуманости джанги это оказалось очень просто. Я потом прикинул — времени потратил ненамного больше, чем если бы сразу сделал с django-registration. Именно из-за того, что шаблоны пришлось бы копать в интернете.
Мне не нравится использование UserProfile. Обычно тоже пишу сам под нужды проекта, а с помощью манкипатча расширяю модель User, обычно эти поля сразу нужны с юзером. Кстати кое-какие фрагменты шаблонов, например для восстановления пароля и логина лежат в contrib.admin. И раз уж используется i18n, то можно позаворачивать русские мессиджи в trans. coolcode — в коде шаблона так и надо?
Да, coolcode, конечно, лишний. Спасибо, убрал. Русские мессаджи я в транс не запихивал, поскольку у сайта будет только русская версия.
А зачем манкипатчить если можно наследоваться от User?
А что уже сделали какой-то хук? все контрибы использую from django.contrib.auth.models import User. Какую проблему решит наследование?
Кстати это идея… Надо попробовать пронаследовать юзера и переопределить бекенд авторизации, чтобы get_user возвращал класс наследника. Может сработать, спасибо за наводку
А чо в этом хорошего? Какая-то модель сбоку приделана через контент тайп. Костыль в виде кеша профилей. Лучше бы сделали какой-то импорт хук, чтобы можно было заменять модуль авторизации своим при помощи наследования юзеров. А в админке есс-но это инлайн объект и нужно переопределять сайт админа, чтобы нормально юзера редактировать. И переопределять админ класс для юзера, ибо изначально имя вверху формы, а отчество и телефон внизу.
НЛО прилетело и опубликовало эту надпись здесь
Лучше слушать сигнал post_save от User.
Речь идет о поднятии объекта из базы и человек демонстрирует как будет в этом орм делаться джоин. При чем тут сейв?
Речь идёт об автоматическом создании профиля при первом к нему запросе (в случае AutoOneToOne, об этом ещё Сагалаев писал очень давно), я предлагаю документированный и более простой вариант создания профиля при создании юзера — нет оверхеда при каждом обращении к профилю.
НЛО прилетело и опубликовало эту надпись здесь
Хорошая альтернатива кстати, наследование моделей тоже это использует, только можно поля профиля прямо подтянуть в юзер, если это важно. Спасибо!
Хорошее там хотя бы в том, что не нужен манкипатчинг. А заменять модуль авторизации через какие-то хуки не есть правильно — потом напоретесь на грабли с совместимостью сторонних приложений и т.п. К тому же профиль к авторизации не относится вообще, так что всё хорошо. Лично я без всяких трудностей использую стандартный документированный подход к профилям.
Джанга построена на магии, и внутрии ее не все так хорошо и надо менять. Комментарием выше я описал «законный способ» расширить модель с помощью наследования. Грабли? Что это? Какая несовместимость, есть таблица юзера остается таблицей юзера? Никто не говорит о трудностях, речь о том, что джанго дает мало хуков и приходится их изобретать. Если есть что-то по существу — могу раскрыть тему.
Если вам реально требуются для решения задачи какие-то хуки — это повод пересмотреть своё решение прежде всего, а потом подумать, правильно ли вы выбрали инструмент решения. А изобретать что-то сверх необходимого не надо.
Инструмент и правда несовершенен :( Конекшн по тупому 1 глобальный, рендереры элементов форм такие, что парню, который писал админку тоже пришлось хакать чекбокс, чтобы он по-человечески отображался (сначала бокс, потом лейба). Кстати админка еще куда-ни шло написана. Но ничего лучшего пока не видно. Парни берут веркцойк, алхимию, джинжа2, втформс и пишут неплохие апликейшны. Если добавить хороший клей и сахар — можно сделать нормальный веб фреймворк и потенциально это будет быстрее, чем джанга пофиксит внутренние проблемы. Кверисет уступает алхимии, нет идентити мап. Шаблонизатор уступает jinja2 по скорости и механизму написания тегов. Так же у джанговского шаблонизатора есть проблема при большой вложенности. Кстати одни мои знакомые вроде начали делать опен сорс фреймворк… если интересно — это тут svarga.piranha.org.ua/
Не, ну а что. Pylons и вперёд, там даже CouchDB есть =)
Один раз был вовлечен в проект на пилонсах, шаблоны мако и sqlobject. Как оскомина пройдет — может еще раз посмотрю… Я смотрю он прогрессирует. А как насчет батареек, имеется?
Не в курсе, я последний раз его щупал года 2 назад. С тех пор только взял на заметку появление CouchDB — и всё. Но уже тогда это было именно то, что вы хотите: суповой набор с клеем.
НЛО прилетело и опубликовало эту надпись здесь
Манкипатчить плохо, я знаю. А вот про такой финт с url не знал — спасибо!
Манкипатчить — хорошо и трогательно. Это не противоречит динамическим принципам питона, добавить в лист бейза еще 1 класс. А насчет порядка урлов, порядка включенных приложений, и прочих порядков — это сходу описано в документации джанги. Хотя я рекомендую потратить 2 часа на прочтение исходников джанги. Это пригодится неоднократно, особенно с рендрингом форм.
Спасибо за статью! Очень бы хотелось побольше статей про Django на хабре. Инструмент, который я люблю все больше и больше и за счет которого все меньше и меньше люблю пехапе.
НЛО прилетело и опубликовало эту надпись здесь
А что тут у многих за проблема с шаблонами?
В доках registration там сразу явно было дано понять, почему их нет:

1. Providing default templates with an application is generally
hard to impossible, because different sites can have such
wildly different design and template structure. Any attempt to
provide templates which would work with all the possibilities
would probably end up working with none of them.

2. (сокращая) Неизвестно, какой у вас шаблонный бекэнд, может и нестандартный. Тогда никакого толка от их шаблона не будет.

Да и вообще, в контексте передается либо только {{ form }} либо вообще ничего (страница редиректа после успешной отправки). А уж как вы форму оформляете и выводите — тут авторам уж точно не узнать.
Так то оно так, но всегда быстрее и удобне править шаблоны, чем выдумывать их заново. Тем паче, что быстро понять, что form.__all__ трансформируется в {{ form.non_field_errors }} получается не всегда. Потому то люди заново пишут регистрации…
НЛО прилетело и опубликовало эту надпись здесь
За renderform — спасибо, гляну.

В данном конкретном случает в форме авторизации в {{ form.non_field_errors }} выводится текст ошибки, если пользователь не активирован. Это важно.

Так и в форме активации, после того, как пользователь себя активировал, но еще раз перешел по ссылке, то {{ account }} равен False. Я в шаблоне уже делаю проверку и говорю, что, мол «ваш аккаунт скорее всего уже активирован».

Мелочи и ньюансы — на них уходит тьма времени.
НЛО прилетело и опубликовало эту надпись здесь
в статье информация по django-registration 0.7, бэкенды появились в 0.8
О, спасибо — этот момент я упустил.
Забыл про темплейт registration/activation_complete.html
url(r'/register', 'registration.views.register', {'form': RegistrationFormUniqueEmail}, name='registration_register') —
в паттерне нет маркеров начала и конца строки, так что эта хрень матчит всё, в чём есть строка '/register'. И accounts надо добавить.
Верное замечание — поправил. Спасибо!
Ещё замечание

Но, как правильно поправил в комментариях lizendir — править код библиотеки — плохо. Лучше в urls.py перед подключением registration.urls добавить свой url () такого вида:
url(r'^register/$', 'registration.views.register', {'form': RegistrationFormUniqueEmail}, name='registration_register'),
url('', include('registration.urls')),

Вот тут надо сказать, что также надо добавить в верху файла
from registration.forms import RegistrationFormUniqueEmail
Вы забыли указать, после тега {% csrf_token %}
В 2009 году, когда писалась статья, csrf еще не было. А так да — надо поставить для корректной работы формы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории