Всем привет!
Когда я впервые столкнулся с Flask, у меня сразу возник вопрос по построению архитектуры проекта.
Прочитав пару статей на Хабре (https://habr.com/ru/post/275099/ и https://habr.com/ru/post/421887/), я вспомнил свой опыт создания проектов на Django, и решил сделать инструмент, благодаря которому не придется задумываться об архитектуре, но при этом можно будет использовать все возможности Flask.
Установка
$ pip install Flask-DJ
Создание проекта
Создать проект можно либо с помощью консоли (для шаблонов и статических файлов используются флаги -t -st)
$ flask-dj startproject app
Либо можно создать файл setup.py
(для шаблонов и статических файлов используются флаги
need_templates=True, need_static=True).
from flask_dj import startproject
from os import getcwd
your_project_name = 'app'
project_dir = getcwd()
startproject(your_project_name, project_dir)
В результате должна получится следующая структура
(static и templates появятся при указании соответствующих флагов)
app/
app/
__init__.py
config.py
urls.py
manage.py
Создание приложения
Приложением в данном случае называется модуль (элемент приложения).
Для создания необходимо прописать следующую команду (вместо index поставить имя вашего приложения).
$ python manage.py startapp index
После выполнения у проекта будет следующая структура:
app/
app/
__init__.py
config.py
urls.py
index/
forms.py
models.py
urls.py
views.py
manage.py
Создаем принимающую (view) функцию
Все гайды принято начинать с Hello world, мы не будем исключением:
# index/views.py
def index():
return "Hello world"
Создаем URL для нашей функции
Создаем относительный путь внутри index:
# index/urls.py
from utils.urls import relative_path
from .views import index
urlpatterns = [
relative_path("", index),
]
Добавляем наше приложение к глобальному пути:
# app/urls.py
from utils.urls import add_relative_path, include
urlpatterns = [
add_relative_path("/", include("index.urls")),
]
Запускаем сервер
$ python manage.py runserver
Если все шаги сделаны верно, то мы увидим следующее
P.S.
Надеюсь данная статья была для вас полезной.
Если вас заинтересовала данная библиотека, то вот ссылки на нее:
- https://github.com/AlexandrovRoman/Flask-DJ
- https://flask-dj.readthedocs.io/en/latest/
- https://pypi.org/project/Flask-DJ/
Upd1 Спасибо buriy за полезные замечания
norguhtar
У меня исключительно один вопрос. Зачем тащить django в flask? Нужен django используйте его. А тащить худшую часть django во flask и игнорировать официальную документацию в которой между прочим есть пункт про то как создавать большие приложения, нууу такое.
prostofilya
Что вы подразумеваете под худшей частью в джанго? И почему?
norguhtar
Вы явно выносите прописывание urls в файл
При этом во всех примерах официальной документации 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
prostofilya
Так а в джанго то что за худшая часть?
norguhtar
Вынос всех urls в отдельный файл. Из-за этого приходится туда сюда переключаться через между модулями. В случае декоратора этого делать не надо и связь функций с url очевидна. Более естественный подход.
prostofilya
По урлам я легко найду используемую вьюшку, а вот если у меня в app, допустим, с десяток различных файлов с вьюшками, то я не представляю как легко и быстро найти мне необходимый урл.
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ше було?
Нет, ну я знаю некоторых приколистов, которые в пересоленное добавляют сахар «для нейтрализации». Это из той же серии?