← All posts tagged Django

demiazz

На проекте, нужно реализовать довольно такую интересную, но очень гемморойную задачу. По сути, авторизация и регистрация — дело плевое, когда это без ивращения. Devise спасает, но когда к пользовательской учетке привязывается профиль с десятками разных связей, и вот из этого чуда надо на nested_forms построить одну большую форму с 3-4 уровнями вложенности, то иногда задумываешься, что Django Forms с JS плагином не так уж страшны :D

demiazz

Django REST Framework продолжает показывать себя с хорошей стороны. Из плюсов использования его с Backbone.js могу точно назвать, что он гарантированно поддерживает Backbone.js на уровне PUT/DELETE запросов, по схеме, которая используется в Ruby On Rails (то есть непосредственной передаче по POST запроса с дополнительным параметром _method = "PUT" в случае PUT, или _method = "DELETE" в случае DELETE.

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

demiazz

Как оказалось, Tastypie, несмотря на всю его красоту, то еще поделие. Автор фреймворка, видите ли отрицательно относится к вложенным ресурсам (а как же без них родимых, ибо 1-2 уровня вложенности не запрещаются ни одним экспертом REST, но очень часто жизненнонеобходимы). В итоге получаем, что чтобы сделать простые GET ресурсы с вложенностью, надо так извращаться над кодом, что этот код становится совершенно не сопровождаем. В итоге отказались от сего поделия, и выбрали более православный, хоть и более молодой Django RESTFramework. Эта умница не только в 20-30 раз кратче делает вложенные ресурсы, причем они по умолчанию поддерживаются без всякого геммороя, но также имеет веб-морду к API — то есть, веб-морда на "поиграться" с API. Причем, он сам понимает, когда ему AJAX подсовывают, а когда стоит страницу для удобного анализа запросов подсунуть клиенту, что очеееень радует. В общем пока нарадоваться не можем, красоте и идеологии сего инструмента. А tastypie забыли как страшный сон, хотя и выглядел он как конфетка.

demiazz

Раскопали старый проект интеграции с нашим приложением, который делали для нынче почившей страховой компании. Все таки стоит снять шляпу перед автором кода, ибо он чистенький и сука красивый, настолько насколько это я могу представить. Шедеврально чистый и хорошо написанный код. Черт. Это аж великолепно.

Но как грится: Python — сила, Django — могила :D (это я сарказничаю о своем неосиляторстве).

demiazz

Если кто нить портирует хелперы форм с рельсов на Django — я его на руках буду носить. Честно. Он будет мой герой. А если я встречу того, кто придумал формы в Django — того я на месте прибью. Просто закопаю нахрен. >_< Мало того что в наследство досталась переиначенная, манкипатченнохуйпойми с каким кодом огромная форма, так мне теперь либо извратиться надо с формой и манкипатчить ее (так как эта падла ModelForm), чтобы добавить эти ебанные CSS классы, которые должны быть в ШАБЛОНЕ (О боги, какой же у меня баттхерт), либо делать суперизвращения со стилями, чтобы добавить сраное выравнивание для сранного поля ввода. Не ну пиздец ли?

demiazz

Вот скажите. Я такой дебил, или формы в Django в части рендеринга не просто ужасны, а хуже не придумать? Ну вот плиз, скажите, ну какой сука идиот придумал класс формы, с полями, и в которых еще виджеты, и только в виджетах CSS-стили (!!!!) CSS-стили в серверном блять коде (!!!!). Ну какого хера. Другого пути я не вижу, или есть таки способ, чтобы рендерить дополнительные параметры не в Python коде, а в шаблонах? искал искал — хрен нашел (((

demiazz

Жуйк. Есть некий сервис на Django. Имеем модель с порядка 15-20 полей, и к ней форму. Порядка десяти полей это связи с другими моделями. Что еще хуже — в форме есть formset.

Сейчас встала такая задача — сделать API, который работает с этой моделью (REST естественно), и использовать одно и то же в разных, интерфейсах. И нужна валидация на стороне клиента.

Ладно бы форма была единообразно — все не так прискорбно было бы. Но вполне возможны разные варианты рендеринга формы, разные условия и данные в селектах, где-то чекбокс, где-то это же поле — радио. Короче форма может иметь кастомные элементы. Собственно в чем вопрос. Встречал ли кто-нить какие-то JS библиотеки, для сложной валидации формы? То есть, к примеру передали описание требований к полям формы (тип, required, тип значения, и прочие), но могут быть и дополнительные зависимости (типа вот этот чекбокс включен — значит эти поля становятся обязательными, а этот отключен — значит они не становятся не обязательными, и тому подобное). Есть ли вообще такие инструменты? Потому что писать каждый раз валидацию сложной формы для каждого интерфейса — не есть хорошо, да к тому же еще если таких интерфейсов несколько — то для каждого надо валидацию, а если что-то на сервере поменяли — то в нескольких интерфейсах поправки еще вносить. В общем, если кто, что знает или может какие-то идеи есть — огромное спасибо.

Рекомендации приветствуются. )

demiazz

Вот что значит старое приложение на костылях с Prototype (без обвинений в сторону Prorotype). В старом куске интерфейса использовались мультиформы, но без всяких плагинов, и каким-то ручным магическим способом добавлялись удалялись, и сделана была огромная костыльная форма для обработки и сохранения в модель. И когда поступал запрос, количество форм в formset сбрасывалось/перебрасывалось, но для чего — непонятно. %) руки бы оторвал. Грешил на свой JS код с jquery.formset.js, а оно вон оно как. Оказалось legacy палки в колеса вставил. >_<

demiazz

Никогда, сука, не пиши scope и методы коллекций как @classmethod'ы, только как методы ObjectManager'а. >_< Это не рельсовая ActiveRecord, где scope'ы и работа с коллекцией идет через методы класса. Это Django ORM, где такие задачи решаются через ObjectManager, и должны быть доступны по Model.objects.your_method. >_<

demiazz

Жуйк. Кто нить на серьезных тяжелых проектах использовал эту связку. Сейчас у нас на одном сервере крутится все. Серв хоть один но мощный, но тем не менее. Какие подводные камни можно ожидать от MongoDB на продакшене? И как она уживается по ресурсам с другим ПО, опять таки SQL DB, веб-серверы и прочие вещи. Рекомендации приветствуются. )

demiazz

Сейчас либо польется куча говен с вентилятора в сторону либо Django, либо MySQLdb, либо в сторону непосредственно MySQL, если я таки не разберусь с этим мракобесием. Как заставить эту связку использовать всегда и везде при syncdb именно utf8_bin, а не latin и прочие ненужные кодировки. Вероятно у меня руки кривые, и выпрямлять надо, но я просто не могу найти где я скривил. Прошу помощи знающих и умеющих готовить это. Закидайте меня советами и ссаными тряпками, если у меня руки кривы. Рекомендации приветствуются

demiazz

Вот еще одна маленькая прелесть, за которую обожаю HAML — он автоматически "сжимает" HTML-код. В отличии от многих стандартных шаблонизаторов типа ERB, Django Templates, Jinja2. Если ERB еще кое как, то пустые две три строки после нормально распределенного и визуально кода шаблоа — просто мозолят глаза. %)

demiazz

Все чаще встречаюсь с разными багами Django ORM. Баги конечно с моей стороны, вызванные то ли большим количеством legacy кода в приложении, и сложной базой (таблиц 50 наверное будет), то ли моим непониманием работы с ней.

demiazz

А есть какие-нить фабрики для тестирования? Типа аналоги рельсовых factory_girls, machinist или blueprint. Видел factory_boy (мертвый кажется). И django-any — хотя так и не увидел особого удобства. Или лучше напрямую писать моделями дела все эти?

demiazz

Вот почему. Почему нигде в доке джанги я не нашел даже малейшего упоминания о том, что при неправильном поле (к примеру, поле установленно null=False), при сохранении модели вызывается исключение IntegrityError. И тут нихуя не очевидно, что такое есть. Есть ValidationError, если не проходит валидация. Но это только через валидаторы. Пиздец. Я зол. А раньше считал доки по Django лучшими в своем роде. Сейчас уже так давно не считаю, увы.

demiazz

*внезапно Внезапно, а Django умеет подхватывать обратные связи o2m, m2m и так далее. Однако с каким синтаксисом это делается, мне честно говоря дико не привычно. А еще ни хрена не понятно, что она собственно делает, и какие запросы там шлет ( Вот блин. Делают джангу уже сколько лет. У них 1 ORM, главная. Неужели так трудно блин сделать dev-консоль как у Rails которая будет выводить статистику и логи по запросам и скорости обработки рендеринга, запросов и прочего. Чтобы не ставить каждый раз django-debug-tools. Ну это звездец товарищи, но средства для разработки не входят в стандартную поставку. Это звездец звездец (((((((( А вы еще про магию рельсов говорите.

demiazz

После знакомства с Rails приходит глубокое осознание того, что "программирование по соглашению" очень крутая и очееееень юзабельная вещь. К примеру работа с шаблонами. Ты вообще не паришься где хранить, как хранить и как называть шаблоны. Тебе совсем не нужно это настраивать и делать прочие вещи. Это просто не нужно в 99% случаев. А разброс куда хочешь, туда и ложи в Django из-за 1% делает неудобным остальное. Эти перекрытия шаблонов и прочее. Ужс. ) Это как пример. Ну не нужна такая свобода. Все должно быть интуитивно понятно, в чем и есть прелесть "программирования по соглашению".