Комментарии 20
А можно подробнее по поводу нелаконичности, неоднозначности и ограничений Django? Складывается впечатление, что Вы в итоге то же самое собрали, только не такое надежное и поддерживаемое в целом.
Присоединяюсь к запросу, мне то же очень интересно узнать какие в Django есть ограничения, с которыми сложно смириться. И что же там монстроузного? Возможно, это будет поводом рассмотреть их внимательнее.
Попробуйте сделать на Django ORM JOIN с дополнительным условием, вида:
Причем, еще желательно туда добавить туда какие-нибудь дочерние объекты select_related'ом дополнительным, чтобы не было желания использовать raw() для QuerySet'а (который вместо трех объектов Author с кучей книг в obj.books_set выдаст кучу объектов Author, каждый с одной книгой в отдельных полях).
Или попобуйте инжектировать request.user в какое-нибудь кастомное поле в админке. Задолбаетесь наследоваться. Это в каждой форме, для каждой модели где есть это поле нужно будет придумывать какие-то миксины или копировать код.
Или кастомные list_display'и для админки с абстрактной моделью сделать. Тоже адские миксины будут. Или переиспользование кода.
Проблема джанги даже не в том, что она большая или перегруженная. А в том, что там очень тесные связи между элементами. Если нужно одно звено поменять/модифицировать — приходится переделывать/наследовать соседние по иерархии использования (а иногда не только соседние) элементы.
Таким образом получаем дикую кашу различных сущностей с непроизносимыми именами на 20+ символов и зависящих друг от друга — наследующих или вызвающих друг друга, — или просто копи-паст разных частей кода. А с учетом того, что Python — нетипизированный язык, а Django еще и имеет кучу динамически создаваемых вещей (те же менеджеры моделей) с этим порой сложно справляться даже при помощи таких замечательных вещей, как PyCharm.
А еще у Джанги нет нормальной* документации по всем методам/свойствам классов. Или хотя бы их списка.
P.S. Также хочу заметить, что я не совсем согласен с автором статьи в том плане, что, на мой взгляд, не стоит из Flask'а (и ему подобных) делать Django с преферансом и куртизанками, копируя его структуру и принципы построения приложений, а пользуясь гибкостью различных компонентов и разумно сочетая их между собой, стоит пытаться строить приложения, которые наилучшим образом подходят именно под ту задачу, которая решается. Не стоит пытаться изобрести универсальное решение (== вторую Джангу), ни к чему хорошему это не приведет — рано или поздно появится та же проблема: новые инструменты или подходы, которые нужны для новых задач, не вписываются в концепцию монолитной платформы.
P.P.S. Спасибо автору за библиотечку webassets, как-то я упустил ее из виду. Возможно, когда-нибудь пригодится.
* — см. документацию Qt или стандартной библиотеки C++, или стандартных библиотек Go, или классов Android.
SELECT a.author_name, b.book_name FROM authors AS a LEFT OUTER JOIN books AS b ON a.id = b.author_id AND b.language = 'French';
Причем, еще желательно туда добавить туда какие-нибудь дочерние объекты select_related'ом дополнительным, чтобы не было желания использовать raw() для QuerySet'а (который вместо трех объектов Author с кучей книг в obj.books_set выдаст кучу объектов Author, каждый с одной книгой в отдельных полях).
Или попобуйте инжектировать request.user в какое-нибудь кастомное поле в админке. Задолбаетесь наследоваться. Это в каждой форме, для каждой модели где есть это поле нужно будет придумывать какие-то миксины или копировать код.
Или кастомные list_display'и для админки с абстрактной моделью сделать. Тоже адские миксины будут. Или переиспользование кода.
Проблема джанги даже не в том, что она большая или перегруженная. А в том, что там очень тесные связи между элементами. Если нужно одно звено поменять/модифицировать — приходится переделывать/наследовать соседние по иерархии использования (а иногда не только соседние) элементы.
Таким образом получаем дикую кашу различных сущностей с непроизносимыми именами на 20+ символов и зависящих друг от друга — наследующих или вызвающих друг друга, — или просто копи-паст разных частей кода. А с учетом того, что Python — нетипизированный язык, а Django еще и имеет кучу динамически создаваемых вещей (те же менеджеры моделей) с этим порой сложно справляться даже при помощи таких замечательных вещей, как PyCharm.
А еще у Джанги нет нормальной* документации по всем методам/свойствам классов. Или хотя бы их списка.
P.S. Также хочу заметить, что я не совсем согласен с автором статьи в том плане, что, на мой взгляд, не стоит из Flask'а (и ему подобных) делать Django с преферансом и куртизанками, копируя его структуру и принципы построения приложений, а пользуясь гибкостью различных компонентов и разумно сочетая их между собой, стоит пытаться строить приложения, которые наилучшим образом подходят именно под ту задачу, которая решается. Не стоит пытаться изобрести универсальное решение (== вторую Джангу), ни к чему хорошему это не приведет — рано или поздно появится та же проблема: новые инструменты или подходы, которые нужны для новых задач, не вписываются в концепцию монолитной платформы.
P.P.S. Спасибо автору за библиотечку webassets, как-то я упустил ее из виду. Возможно, когда-нибудь пригодится.
* — см. документацию Qt или стандартной библиотеки C++, или стандартных библиотек Go, или классов Android.
очень часто джанге приписывают сложности кастомизации админки, не приводя при этом сколь нибудь достойнного аналога
Я боюсь, что его и нет ;) Суть проста: хочешь быстро и просто — используй джангу, хочешь сложнее и кастомизабельнее — пиши сам/собирай из разных компонентов. Маленький сайт быстро и просто писать на джанге, когда пишешь большой и сложный — больше копаешься в исходниках джанги, чем пишешь свой вариант.
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. Наполняем «флягу» функционалом