Комментарии 20
А можно подробнее по поводу нелаконичности, неоднозначности и ограничений Django? Складывается впечатление, что Вы в итоге то же самое собрали, только не такое надежное и поддерживаемое в целом.
Присоединяюсь к запросу, мне то же очень интересно узнать какие в Django есть ограничения, с которыми сложно смириться. И что же там монстроузного? Возможно, это будет поводом рассмотреть их внимательнее.
1. Django состоит из огромного количества модулей, хелперов, приложений. Уверен, кем-то это всё используется по-полной, но в случае несложных проектов монструозный функционал избыточен: если, скажем, нужно прикрутить аунтефикацию, то используется contib.auth, а там багажом получим в базе groups и permissions. Вроде и не мешают, а вроде никто и не приглашал.
2. Django многие вещи позволяет сделать несколькими путями. Кому-то это по душе, но точно не мне. Пример? — render_to_respose, render, HttpResponse.
3. Ограничения? На структуру проекта, на используемую модель юзера(да, я в курсе про изменения в 1.5), на ORM. Можно, конечно, и прикрутить, что надо, но вряд ли это будет проще, чем во Flask или Pyramid.
Я ни в коем случае не противник Django, просто это не мой выбор. Может быть, я просто его не понял.
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, но это наверняка и так всем известно =)
Отдельное спасибо за wtforms-alchemy, не знал про неё, а boilerplate формы клепать уже достало…
Ещё с Фласком регулярно используют шаблонизатор Jinja2, но это наверняка и так всем известно =)
Первый раз читаю применительно к django о том, что обилие сторонних библиотек отпугивает. Так сходу и не смогу назвать категорию функционала, которую хорошо покрывают сразу множество подобных друг другу актуальных (это важно!) библиотек.
Насчет актуальности есть вопросы. Если попробовать, например, найти рабочую и простую библиотеку, скажем, для OpenID — их примерно 5-6 альтернатив и некоторые из них в новой версии джанги уже не работают.
Поддерживая проект на Django, я чаще не программирую, а ищу нужный функционал в батарейках. :) Была как-то необходимость добавить select2 в проект. После рассмотрения нескольких примочек для django, забил и сделал всё «вручную».
Чтобы получить описанный автором статьи скелет проекта, готовый к использованию, можно воспользоваться «печенько-резем»: github.com/sloria/cookiecutter-flask
сложности кастомизации админки, не приводя при этом сколь нибудь достоенного аналога
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flask. Наполняем «флягу» функционалом