Flask. Наполняем «флягу» функционалом

[alrusdi]

А можно подробнее по поводу нелаконичности, неоднозначности и ограничений Django? Складывается впечатление, что Вы в итоге то же самое собрали, только не такое надежное и поддерживаемое в целом.

[Dominis]

Присоединяюсь к запросу, мне то же очень интересно узнать какие в Django есть ограничения, с которыми сложно смириться. И что же там монстроузного? Возможно, это будет поводом рассмотреть их внимательнее.

[freylis]

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

[bIbI4k0]

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

[Dominis]

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, просто это не мой выбор. Может быть, я просто его не понял.

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

[Kulver]

А почему именно Flask-Migrate, а не alembic? Есть какие-то причины, или «просто так сложилось»?

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

Ещё с Фласком регулярно используют шаблонизатор Jinja2, но это наверняка и так всем известно =)

[enchantner]

Если я правильно помню, flask-migrate — это и есть тонкая обертка над alembic.

[bIbI4k0]

Migrae — это тоже обертка вокруг Alembic, но выбор пал на неё именно благодаря наличию готовой команды для управления миграциями. Хотя, признаюсь, я уже и не помню, рассматривал ли альтернативы. :)

[freylis]

Первый раз читаю применительно к django о том, что обилие сторонних библиотек отпугивает. Так сходу и не смогу назвать категорию функционала, которую хорошо покрывают сразу множество подобных друг другу актуальных (это важно!) библиотек.

[enchantner]

Насчет актуальности есть вопросы. Если попробовать, например, найти рабочую и простую библиотеку, скажем, для OpenID — их примерно 5-6 альтернатив и некоторые из них в новой версии джанги уже не работают.

[freylis]

Я это и имел ввиду. Если и имеется реально больше 2-3х аналогов, то работают на текущей версии django отсилы 1-2

[bIbI4k0]

Поддерживая проект на Django, я чаще не программирую, а ищу нужный функционал в батарейках. :) Была как-то необходимость добавить select2 в проект. После рассмотрения нескольких примочек для django, забил и сделал всё «вручную».

[Aft3rmath]

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

[danSamara]

Чтобы получить описанный автором статьи скелет проекта, готовый к использованию, можно воспользоваться «печенько-резем»: github.com/sloria/cookiecutter-flask

[bIbI4k0]

Не знал об этом проекте. Спасибо!

[danSamara]

Можно в пост добавить ;)

[freylis]

сложности кастомизации админки, не приводя при этом сколь нибудь достоенного аналога

[freylis]

прошу прощения, с приложения как-то коряво получилось отправить комментарий