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

image


Всем привет!


Когда я впервые столкнулся с 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

Если все шаги сделаны верно, то мы увидим следующее


image


P.S.


Надеюсь данная статья была для вас полезной.


Если вас заинтересовала данная библиотека, то вот ссылки на нее:



Upd1 Спасибо buriy за полезные замечания

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 22

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


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

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

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

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

            В django да. В случае flask нет. Почему так в документации привел.
              0
              да ничего, я к тому, что придется добавлять логику для импорта/автоимпорта таких файлов (скажем, views.py)
              С urls.py немного иначе, так как достаточно загрузить только корневой `myproject/urls.py` который зампортит все зависимости.
                +1
                У вас это и так делается в urls.py. Ну и сходите посмотрите как выглядит blueprint в flask. Просто вы сейчас заносите в flask django. В flask своя другая идеология построения приложений.
                  0
                  Концепции, которые исповедуют джанга и фласк, разные. Джанга — это «out of the box» монстр, эдакий бутстрап для веб-проектов на Питоне. Фласк — это «конструктор Лего», где вы строите все с нуля из маленьких кирпичиков по мере надобности. Первый — как MacOS: все есть и гарантировано работает в пределах забора. Второй — как Gentoo: можно собрать любую ось, если есть время и желание. Первый хорош на старте, второй — для уже развернутых проектов, которым, скажем, тесно в экосистеме джанго. Подходы разные, стиль кода в проектах разный, да и подкапотная часть весьма различается.

                  Как вывод, не вижу профита в создании некоего котопса.
                    0
                    Учитывая что сейчас большая часть web-приложений это SPA монстр становится избыточным.
                      0
                      А что меняется, если django будет отдавать не html который был генерирован из шаблона, а какой нибудь json?
                      Даже если SPA, все равно для django остается много работы: авторизация, модели и пр. Ну и ее величество админка, написание которой ручками может занимать половину работы над проектом.
                        0
                        Как минимум там не нужен forms, а views больше становится уже про логику приложения. Админка ну такое. Мне не особо нравилась в django как собственно и само django
              0
              Так а в джанго то что за худшая часть?
                0
                Вынос всех urls в отдельный файл. Из-за этого приходится туда сюда переключаться через между модулями. В случае декоратора этого делать не надо и связь функций с url очевидна. Более естественный подход.
                  0
                  По урлам я легко найду используемую вьюшку, а вот если у меня в app, допустим, с десяток различных файлов с вьюшками, то я не представляю как легко и быстро найти мне необходимый урл.
                    0
                    Вообще у всех нормальных людей это делается через адекватные имена модулей. В flask мне не требуется плодить структуру вида

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


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

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

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


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

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

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

                  В итоге что так искать что так искать. Так в случае декларативного объявления не надо идти в другой файл.
                –1
                Насчет «худших частей» я тоже не согласен. Но действительно — зачем?
                Это очень разные продукты для разных сегментов. Нафейхоа?
                Шо б смiшниiше було?
                Нет, ну я знаю некоторых приколистов, которые в пересоленное добавляют сахар «для нейтрализации». Это из той же серии?
              0
              Мне нравится в целом проект.
              Что хорошо сделано: подготовка файлов и runserver, прямо облегчают старт проекта, особенно для новичка во flask.
              Что сильно не нравится: заглавные буквы в именах (это не стиль питона, надо писать flask-dj и flask_dj, а не Flask-DJ, а лучше просто использовать единое имя flask_dj вместо двух разных написаний)
              Непонятное: ProjectConstructor(your_project_name, project_dir).startproject() — это генерирование файлов? тогда надо называть «Generator», и почему вообще это не сделать методом с двумя параметрами, а этот конкретный способ реализации засунуть вовнутрь?
                0
                Спасибо за отзыв, рад что вам понравился проект. Сейчас имя модуля уже поздновато менять, так что оставлю название как есть. Название для импорта думаю действительно стоит поменять. ProjectConstructor создает файлы проекта. В принципе можно инкапсулировать в отдельный метод startproject.
                0
                По поводу отличия urls и вообще отличия django и flask — ребята, эти отличия только у вас в голове, нет никакой «другой области применимости» и всего прочего, и в django тоже можно urls декоратором писать, но я не очень представляю, как вы с декораторами один модуль подключите два раза с разными или даже просто меняющимися урлами (правда, это редко нужно, но без этого нет никакого смысла в модульности).
                (Вы говорите, что flask — это набор кубиков лего, но и выбор формата urls — это тоже лего!)
                Данный проект и пытается как раз сделать ближе интерфейсы flask и django, чтобы их было удобнее использовать тому, кто хорошо разбирается в django.
                  0
                  Вообще говоря легко. Просто сделаю два вызова одной и той же функции. При этом создав две разные функции. Более того в django с большей долей вероятности вы сделаете точно так же.

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

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое