Pull to refresh

Comments 20

А можно подробнее по поводу нелаконичности, неоднозначности и ограничений Django? Складывается впечатление, что Вы в итоге то же самое собрали, только не такое надежное и поддерживаемое в целом.
Присоединяюсь к запросу, мне то же очень интересно узнать какие в Django есть ограничения, с которыми сложно смириться. И что же там монстроузного? Возможно, это будет поводом рассмотреть их внимательнее.
UFO landed and left these words here
очень часто джанге приписывают сложности кастомизации админки, не приводя при этом сколь нибудь достойнного аналога
UFO landed and left these words here
1. Django состоит из огромного количества модулей, хелперов, приложений. Уверен, кем-то это всё используется по-полной, но в случае несложных проектов монструозный функционал избыточен: если, скажем, нужно прикрутить аунтефикацию, то используется contib.auth, а там багажом получим в базе groups и permissions. Вроде и не мешают, а вроде никто и не приглашал.
2. Django многие вещи позволяет сделать несколькими путями. Кому-то это по душе, но точно не мне. Пример? — render_to_respose, render, HttpResponse.
3. Ограничения? На структуру проекта, на используемую модель юзера(да, я в курсе про изменения в 1.5), на ORM. Можно, конечно, и прикрутить, что надо, но вряд ли это будет проще, чем во Flask или Pyramid.
Я ни в коем случае не противник Django, просто это не мой выбор. Может быть, я просто его не понял.
1 <...> Вроде и не мешают, а вроде никто и не приглашал.

Я под термином «монстроузность» понимаю избыточный функционал который либо мешает, либо жрёт дополнительные ресурсы в недопустимых количествах. Приведённый вами пример, лично для меня не есть признак монстроузности. Лежат, кушать не просят. Вдруг понадобятся — ничего не нужно делать, только настроить. Не понадобятся? Ну и Бог с ними.
2. Django многие вещи позволяет сделать несколькими путями. Кому-то это по душе, но точно не мне. Пример? — render_to_respose, render, HttpResponse.

Приведённые вами функции не равнозначны, и служат как раз для гибкости и удобства. Нужно вернуть статус 200? return HttpResponse(200). Нужен просто обычный ответ? render_to_response(). Нужно что-то накрутить хитрое? render с кучей параметров. Я с одной стороны согласен, что это избыточно. Но с другой — не избыточный путь это оставить только HttpResponse, что вынудит любого из нас написать свою обёртку для удобства. Чтобы не передавать каждый раз кучу вещей вроде content_type, статус и т.д. Как по мне — гораздо удобнее использовать raise Http404 чем возвращать HttpResponse(status=404). Но соглашусь, что это дело вкуса. Хуже того, в наших проектах на Django используется собственный декоратор render_to, построенный на основе render, насколько я помню. И в 95% случаев мы работаем именно через него. Нам так удобнее.
3. Ограничения? На структуру проекта

Хм, ни разу не испытывал неудобства из-за структуры джанго-проектов. Но, возможно, мне просто не попадалась такая задача. Про юзеров — согласен, было не очень удобно и приходилось отчасти костылить. Однако решается всё довольно просто и очевидно. К сожалению что там после 1.5 сделали я знаю только из прочтения changelog-а. Старые проекты пока держим на 1.4, а в новых юзеры просты до тупости, так что на практике не щупал :(
А с ограничениями ORM согласен. Если надо что-то сложнее чем примитив — бывает геморрой.
Я ни в коем случае не противник Django, просто это не мой выбор. Может быть, я просто его не понял.

Я спрашивал не для спора о том, что лучше. Исключительно с целью разобраться. Может быть я привык к каким-то вещам и просто их не замечаю? Критичный взгляд порой полезен.
А почему именно Flask-Migrate, а не alembic? Есть какие-то причины, или «просто так сложилось»?

Отдельное спасибо за wtforms-alchemy, не знал про неё, а boilerplate формы клепать уже достало…

Ещё с Фласком регулярно используют шаблонизатор Jinja2, но это наверняка и так всем известно =)
Если я правильно помню, flask-migrate — это и есть тонкая обертка над alembic.
Migrae — это тоже обертка вокруг Alembic, но выбор пал на неё именно благодаря наличию готовой команды для управления миграциями. Хотя, признаюсь, я уже и не помню, рассматривал ли альтернативы. :)
Первый раз читаю применительно к django о том, что обилие сторонних библиотек отпугивает. Так сходу и не смогу назвать категорию функционала, которую хорошо покрывают сразу множество подобных друг другу актуальных (это важно!) библиотек.
Насчет актуальности есть вопросы. Если попробовать, например, найти рабочую и простую библиотеку, скажем, для OpenID — их примерно 5-6 альтернатив и некоторые из них в новой версии джанги уже не работают.
Я это и имел ввиду. Если и имеется реально больше 2-3х аналогов, то работают на текущей версии django отсилы 1-2
Поддерживая проект на Django, я чаще не программирую, а ищу нужный функционал в батарейках. :) Была как-то необходимость добавить select2 в проект. После рассмотрения нескольких примочек для django, забил и сделал всё «вручную».
Я в этом вижу только плюсы: первый раз вы искали, второй раз просто используете. Просто не забывайте читать код этих самых батареек, тем более он в своем большинстве очень хорошего качества.
Не знал об этом проекте. Спасибо!
сложности кастомизации админки, не приводя при этом сколь нибудь достоенного аналога
прошу прощения, с приложения как-то коряво получилось отправить комментарий
Sign up to leave a comment.

Articles