Flask-DJ: Django (mvc) структура для проекта на flask

[@norguhtar]

У меня исключительно один вопрос. Зачем тащить django в flask? Нужен django используйте его. А тащить худшую часть django во flask и игнорировать официальную документацию в которой между прочим есть пункт про то как создавать большие приложения, нууу такое.

[@norguhtar]

Вы явно выносите прописывание urls в файл

  urls.py

При этом во всех примерах официальной документации url добавляют через декоратор прямо на функцию. Прям на официальной странице в примере коде так сделано. И по мне так это заметно удобнее чем прописывать и сопровождать файл urls.py

[@mariner]

В случае декоратора, урл не добавится в роутер, пока модуль не будет импортирован (я не про фласк, а в целом).
Имхо явный список в заранее известном файле более выглядит стандартно.

[@norguhtar]

В случае декоратора, урл не добавится в роутер, пока модуль не будет импортирован (я не про фласк, а в целом).

Иии? В случае urls.py все ровно точно так же.

Имхо явный список в заранее известном файле более выглядит стандартно.

В django да. В случае flask нет. Почему так в документации привел.

[@mariner]

да ничего, я к тому, что придется добавлять логику для импорта/автоимпорта таких файлов (скажем, views.py)
С urls.py немного иначе, так как достаточно загрузить только корневой `myproject/urls.py` который зампортит все зависимости.

[@norguhtar]

У вас это и так делается в urls.py. Ну и сходите посмотрите как выглядит blueprint в flask. Просто вы сейчас заносите в flask django. В flask своя другая идеология построения приложений.

[@albartash]

Концепции, которые исповедуют джанга и фласк, разные. Джанга — это «out of the box» монстр, эдакий бутстрап для веб-проектов на Питоне. Фласк — это «конструктор Лего», где вы строите все с нуля из маленьких кирпичиков по мере надобности. Первый — как MacOS: все есть и гарантировано работает в пределах забора. Второй — как Gentoo: можно собрать любую ось, если есть время и желание. Первый хорош на старте, второй — для уже развернутых проектов, которым, скажем, тесно в экосистеме джанго. Подходы разные, стиль кода в проектах разный, да и подкапотная часть весьма различается.

Как вывод, не вижу профита в создании некоего котопса.

[@norguhtar]

Учитывая что сейчас большая часть web-приложений это SPA монстр становится избыточным.

[@kAIST]

А что меняется, если django будет отдавать не html который был генерирован из шаблона, а какой нибудь json?
Даже если SPA, все равно для django остается много работы: авторизация, модели и пр. Ну и ее величество админка, написание которой ручками может занимать половину работы над проектом.

[@norguhtar]

Как минимум там не нужен forms, а views больше становится уже про логику приложения. Админка ну такое. Мне не особо нравилась в django как собственно и само django

[@norguhtar]

Вынос всех urls в отдельный файл. Из-за этого приходится туда сюда переключаться через между модулями. В случае декоратора этого делать не надо и связь функций с url очевидна. Более естественный подход.

[@norguhtar]

Вообще у всех нормальных людей это делается через адекватные имена модулей. В flask мне не требуется плодить структуру вида

index/
forms.py
models.py
urls.py
views.py


Я могу спокойно вынести модели в отдельный пакет, а views просто в отдельный модуль blueprint. Далее blueprint подключить уже в приложении куда надо.

Ну и в случае отдельных urls есть проблема, когда я смотрю в views мне чтобы узнать за какой url отвечает функция надо идти в файл urls.py. В случае декоратора не требуется.

[@NeZanyat]

Чем конкретно это худшая часть?

Я понимаю причины по которым такой подход может не устраивать, но у него все равно есть преимущества. Может и не при написании проекта с нуля а при поддержке, но Reverse Engineering становится существенно проще когда у тебя есть список всех View с соответствующими URL, чем когда приходится искать по всему проекту то что нужно.

[@norguhtar]

Постоянное переключение контекста. Вам надо постоянно держать два файла чтобы соотносить url и фактически исполняемый код. Это реально не удобно. Этого уже не было в spring framework 2.5 2007 года выпуска. А сейчас все стараются делать такую нотацию.

Более того когда у вас там становится под 30 хотя бы вызовов, вы начинаете распиливать это дело по модулям. В случае когда url объявляется декоратором это проще и удобнее делать. И более того вы начнете делать это раньше. В случае urls+views будет в двое больше файлов.

В итоге что так искать что так искать. Так в случае декларативного объявления не надо идти в другой файл.

[@justhabrauser]

Насчет «худших частей» я тоже не согласен. Но действительно — зачем?
Это очень разные продукты для разных сегментов. Нафейхоа?
Шо б смiшниiше було?
Нет, ну я знаю некоторых приколистов, которые в пересоленное добавляют сахар «для нейтрализации». Это из той же серии?

[@buriy]

Мне нравится в целом проект.
Что хорошо сделано: подготовка файлов и runserver, прямо облегчают старт проекта, особенно для новичка во flask.
Что сильно не нравится: заглавные буквы в именах (это не стиль питона, надо писать flask-dj и flask_dj, а не Flask-DJ, а лучше просто использовать единое имя flask_dj вместо двух разных написаний)
Непонятное: ProjectConstructor(your_project_name, project_dir).startproject() — это генерирование файлов? тогда надо называть «Generator», и почему вообще это не сделать методом с двумя параметрами, а этот конкретный способ реализации засунуть вовнутрь?

[@AlexandrovRoman]

Спасибо за отзыв, рад что вам понравился проект. Сейчас имя модуля уже поздновато менять, так что оставлю название как есть. Название для импорта думаю действительно стоит поменять. ProjectConstructor создает файлы проекта. В принципе можно инкапсулировать в отдельный метод startproject.

[@buriy]

По поводу отличия urls и вообще отличия django и flask — ребята, эти отличия только у вас в голове, нет никакой «другой области применимости» и всего прочего, и в django тоже можно urls декоратором писать, но я не очень представляю, как вы с декораторами один модуль подключите два раза с разными или даже просто меняющимися урлами (правда, это редко нужно, но без этого нет никакого смысла в модульности).
(Вы говорите, что flask — это набор кубиков лего, но и выбор формата urls — это тоже лего!)
Данный проект и пытается как раз сделать ближе интерфейсы flask и django, чтобы их было удобнее использовать тому, кто хорошо разбирается в django.

[@norguhtar]

Вообще говоря легко. Просто сделаю два вызова одной и той же функции. При этом создав две разные функции. Более того в django с большей долей вероятности вы сделаете точно так же.

Разница же заключатеся в том что в случае django я до сих пор ожидаю увидеть urls.py в случае flask я ожидаю увидеть url декоратором. Хорошая практика это использовать те подходы что описаны в документации. Именно это цель фреймворка. Чтобы человек знающий фреймворк пришел и смог разобраться сам где тут что. А предлагаемый модуль ломает этот подход.