Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
У меня исключительно один вопрос. Зачем тащить django в flask? Нужен django используйте его. А тащить худшую часть django во flask и игнорировать официальную документацию в которой между прочим есть пункт про то как создавать большие приложения, нууу такое.
Вы явно выносите прописывание urls в файл
При этом во всех примерах официальной документации url добавляют через декоратор прямо на функцию. Прям на официальной странице в примере коде так сделано. И по мне так это заметно удобнее чем прописывать и сопровождать файл urls.py
urls.py
При этом во всех примерах официальной документации url добавляют через декоратор прямо на функцию. Прям на официальной странице в примере коде так сделано. И по мне так это заметно удобнее чем прописывать и сопровождать файл urls.py
В случае декоратора, урл не добавится в роутер, пока модуль не будет импортирован (я не про фласк, а в целом).
Имхо явный список в заранее известном файле более выглядит стандартно.
Имхо явный список в заранее известном файле более выглядит стандартно.
В случае декоратора, урл не добавится в роутер, пока модуль не будет импортирован (я не про фласк, а в целом).
Иии? В случае urls.py все ровно точно так же.
Имхо явный список в заранее известном файле более выглядит стандартно.
В django да. В случае flask нет. Почему так в документации привел.
да ничего, я к тому, что придется добавлять логику для импорта/автоимпорта таких файлов (скажем, views.py)
С urls.py немного иначе, так как достаточно загрузить только корневой `myproject/urls.py` который зампортит все зависимости.
С urls.py немного иначе, так как достаточно загрузить только корневой `myproject/urls.py` который зампортит все зависимости.
У вас это и так делается в urls.py. Ну и сходите посмотрите как выглядит blueprint в flask. Просто вы сейчас заносите в flask django. В flask своя другая идеология построения приложений.
Концепции, которые исповедуют джанга и фласк, разные. Джанга — это «out of the box» монстр, эдакий бутстрап для веб-проектов на Питоне. Фласк — это «конструктор Лего», где вы строите все с нуля из маленьких кирпичиков по мере надобности. Первый — как MacOS: все есть и гарантировано работает в пределах забора. Второй — как Gentoo: можно собрать любую ось, если есть время и желание. Первый хорош на старте, второй — для уже развернутых проектов, которым, скажем, тесно в экосистеме джанго. Подходы разные, стиль кода в проектах разный, да и подкапотная часть весьма различается.
Как вывод, не вижу профита в создании некоего котопса.
Как вывод, не вижу профита в создании некоего котопса.
Учитывая что сейчас большая часть web-приложений это SPA монстр становится избыточным.
Вынос всех urls в отдельный файл. Из-за этого приходится туда сюда переключаться через между модулями. В случае декоратора этого делать не надо и связь функций с url очевидна. Более естественный подход.
Вообще у всех нормальных людей это делается через адекватные имена модулей. В flask мне не требуется плодить структуру вида
Я могу спокойно вынести модели в отдельный пакет, а views просто в отдельный модуль blueprint. Далее blueprint подключить уже в приложении куда надо.
Ну и в случае отдельных urls есть проблема, когда я смотрю в views мне чтобы узнать за какой url отвечает функция надо идти в файл urls.py. В случае декоратора не требуется.
index/
forms.py
models.py
urls.py
views.py
Я могу спокойно вынести модели в отдельный пакет, а views просто в отдельный модуль blueprint. Далее blueprint подключить уже в приложении куда надо.
Ну и в случае отдельных urls есть проблема, когда я смотрю в views мне чтобы узнать за какой url отвечает функция надо идти в файл urls.py. В случае декоратора не требуется.
Чем конкретно это худшая часть?
Я понимаю причины по которым такой подход может не устраивать, но у него все равно есть преимущества. Может и не при написании проекта с нуля а при поддержке, но Reverse Engineering становится существенно проще когда у тебя есть список всех View с соответствующими URL, чем когда приходится искать по всему проекту то что нужно.
Постоянное переключение контекста. Вам надо постоянно держать два файла чтобы соотносить url и фактически исполняемый код. Это реально не удобно. Этого уже не было в spring framework 2.5 2007 года выпуска. А сейчас все стараются делать такую нотацию.
Более того когда у вас там становится под 30 хотя бы вызовов, вы начинаете распиливать это дело по модулям. В случае когда url объявляется декоратором это проще и удобнее делать. И более того вы начнете делать это раньше. В случае urls+views будет в двое больше файлов.
В итоге что так искать что так искать. Так в случае декларативного объявления не надо идти в другой файл.
Более того когда у вас там становится под 30 хотя бы вызовов, вы начинаете распиливать это дело по модулям. В случае когда url объявляется декоратором это проще и удобнее делать. И более того вы начнете делать это раньше. В случае urls+views будет в двое больше файлов.
В итоге что так искать что так искать. Так в случае декларативного объявления не надо идти в другой файл.
Насчет «худших частей» я тоже не согласен. Но действительно — зачем?
Это очень разные продукты для разных сегментов. Нафейхоа?
Шо б смiшниiше було?
Нет, ну я знаю некоторых приколистов, которые в пересоленное добавляют сахар «для нейтрализации». Это из той же серии?
Это очень разные продукты для разных сегментов. Нафейхоа?
Шо б смiшниiше було?
Нет, ну я знаю некоторых приколистов, которые в пересоленное добавляют сахар «для нейтрализации». Это из той же серии?
Мне нравится в целом проект.
Что хорошо сделано: подготовка файлов и runserver, прямо облегчают старт проекта, особенно для новичка во flask.
Что сильно не нравится: заглавные буквы в именах (это не стиль питона, надо писать flask-dj и flask_dj, а не Flask-DJ, а лучше просто использовать единое имя flask_dj вместо двух разных написаний)
Непонятное: ProjectConstructor(your_project_name, project_dir).startproject() — это генерирование файлов? тогда надо называть «Generator», и почему вообще это не сделать методом с двумя параметрами, а этот конкретный способ реализации засунуть вовнутрь?
Что хорошо сделано: подготовка файлов и runserver, прямо облегчают старт проекта, особенно для новичка во flask.
Что сильно не нравится: заглавные буквы в именах (это не стиль питона, надо писать flask-dj и flask_dj, а не Flask-DJ, а лучше просто использовать единое имя flask_dj вместо двух разных написаний)
Непонятное: ProjectConstructor(your_project_name, project_dir).startproject() — это генерирование файлов? тогда надо называть «Generator», и почему вообще это не сделать методом с двумя параметрами, а этот конкретный способ реализации засунуть вовнутрь?
По поводу отличия urls и вообще отличия django и flask — ребята, эти отличия только у вас в голове, нет никакой «другой области применимости» и всего прочего, и в django тоже можно urls декоратором писать, но я не очень представляю, как вы с декораторами один модуль подключите два раза с разными или даже просто меняющимися урлами (правда, это редко нужно, но без этого нет никакого смысла в модульности).
(Вы говорите, что flask — это набор кубиков лего, но и выбор формата urls — это тоже лего!)
Данный проект и пытается как раз сделать ближе интерфейсы flask и django, чтобы их было удобнее использовать тому, кто хорошо разбирается в django.
(Вы говорите, что flask — это набор кубиков лего, но и выбор формата urls — это тоже лего!)
Данный проект и пытается как раз сделать ближе интерфейсы flask и django, чтобы их было удобнее использовать тому, кто хорошо разбирается в django.
Вообще говоря легко. Просто сделаю два вызова одной и той же функции. При этом создав две разные функции. Более того в django с большей долей вероятности вы сделаете точно так же.
Разница же заключатеся в том что в случае django я до сих пор ожидаю увидеть urls.py в случае flask я ожидаю увидеть url декоратором. Хорошая практика это использовать те подходы что описаны в документации. Именно это цель фреймворка. Чтобы человек знающий фреймворк пришел и смог разобраться сам где тут что. А предлагаемый модуль ломает этот подход.
Разница же заключатеся в том что в случае django я до сих пор ожидаю увидеть urls.py в случае flask я ожидаю увидеть url декоратором. Хорошая практика это использовать те подходы что описаны в документации. Именно это цель фреймворка. Чтобы человек знающий фреймворк пришел и смог разобраться сам где тут что. А предлагаемый модуль ломает этот подход.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flask-DJ: Django (mvc) структура для проекта на flask