Имеет ли смысл объединение templates- и static-директорий для реализации компонентного подхода во front-end Django- и Flask-проектов?

Question

[Руслан Гильфанов]

Рекомендуемая в документации Flask и Django структура файлов разделяет по разным директориям HTML-шаблоны от связанных с ними статических файлов (CSS, JavaScript и графические файлы).

Это разделение упрощает конфигурацию HTTP-сервера:

• статические файлы должны раздаваться HTTP-сервером напрямую;
  
• HTML-шаблоны обрабатываются Python-приложением, результат идёт через WSGI-сервер к http-серверу.
  

В Django для упрощения раздачи статистики из коробки доступна команда collectstatic, собирающая все статические файлы в одной директории.

Так что, для раздачи статики через тот же NGINX можно будет указать один конкретный путь:

location /static/ {
        alias /home/project/project-env/project/static/;
    }

Но, в разработке кажется выгодным объединять static и templates в одну директорию, чтобы держать связанные HTML, CSS и JS файлы как можно ближе, реализуя иерархию более-менее независимых компонентов (блоки в методологии БЭМ).

Организовать полноценную иерархию компонентов проще с шаблонизатором Jinja2. В сравнении с шаблонизатором Django, в Jinja2 больше механизмов для расширения и включения шаблонов, изоляции пространств имён и контекста.

При этом, как я понимаю, NGINX может напрямую раздавать файлы с определённым расширением (*.js, *.css и так далее). А значит многоуровневую компонентную файловую структуру можно оставить и в production.

Однако, я не смог найти никакой информации о преимуществах и недостатках объединения static- и templates-директорий.

Собственно вопрос, в Django/Flask в чём преимущества и недостатки:

1. классического подхода с разделением фронтенда на static и templates
   
2. и БЭМ-подобного подхода с разделением фронтенда на более независимые компоненты, причём более-менее штатными для Django/Flask средствами?
   

P.S. Речь не о разделении всего проекта на applications/blueprints, а о структуре front-end внутри этих applications/blueprints.

Comments

[i]

Где можно посмотреть исходную структуру проекта?

Answer 1

[Слава Анжиганов]

В этом случае лучше использовать библиотеку Flask-Themes, чтобы указать расположение статики и шаблонов вне модуля не засорять его.

Comments

[Руслан Гильфанов]

Чтобы хранить шаблоны и статику вне блюпринтов?

Для этого можно указать аргументы template_folder и static_folder при инициализации приложения:

app = Flask(__name__, template_folder='front_end',
            static_folder='front_end', static_url_path='/assets')

Но мне кажется удобнее всё же делить статику и шаблоны по блюпринтам:

project/
    blueprint_1/
        front_end/
            base_page/
                scripts.js
                styles.css
                template.html
            main_menu/
                scripts.js
                styles.css
                template.html
    blueprint_2/
        front_end/
            alt_page/
                scripts.js
                styles.css
                template.html

Для простоты настройки nginx под раздачу статики, хотелось бы потом собирать её из блюпринтов в каком-нибудь static_root (как в Django).

Библиотека Flask-Collect вроде не умеет игнорировать .html-файлы при сборке статики. Раздавать шаблоны jinja2 за компанию -- как-то не вяжется с безопасностью. Писать скрипт, что будет обходить все подпапки static_root и удалять шаблоны -- эталон костылестроения.

Flask-Assets подходит для сборки и минимизации .css- и .js-файлов блюпринтов в общей папке статики, но собирать файлы изображений вроде не умеет.

[Слава Анжиганов]

Flask-Themes позволяет хранить статику в совершенно отдельной директории. Для меня это лучше всего подходит, так как все приложения устанавливаются через pip или deb, а в пакетах хранятся шаблоны и статика по умолчанию, а в директории например, /var/www/mysuperproject.com находится копия, к которой есть доступ на изменение (по ftp например) и эти изменения поступят в пакет только в следующей версии продукта.
Такой подход позволяет не выпускать новую версию пакета из-за неправильного номера телефона или частых изменений в css.