У jq появилась реактивность?

Это был стеб, не воспринимайте это сообщение всерьез)

Коллеги, нужен ваш совет. Нужно создать систему на сеть предприятий. Для каждого она одинаковая просто отдельная бд. и нужно чтоб это отображалось в админке главной системы. Пока у меня такая идея: создать отдельный проект для предприятияб с этим проблем нет. Я в некотором затруднении как потом получать в админку главного проекта данные из побочных. Я прочитал про использование нескольких баз данных в джанго. Пока думаю создать таблицу вида [предприятие - псевдоним бд] и подредактировать админку. Может кто то что то подобное уже реализовывал? Архитектура именно такая, поменять не могу. Заказчик хочет чтоб в случае проблем со связью каждое отдельное предприятие могло продолжать работу. Кто может подкинуть полезных советов или идей?

Postgres

ну, про Vue.js долго писать не буду - понятно, что это лучший вариант сегодня и для SPA и для SSR, можно сказать, что это хороший вариант по умолчанию для новых проектов и большая часть людей это уже понимает, это же показывают и результаты опроса хотя казалось бы, опрос в группе, где должен был бы победить первый вариант) [некоторые предлагают вместо Vue.js React или Angular или что-нибудь ещё, это уже частные случаи того же подхода - рендерим шаблоны js'ом, в данном контексте этот спор про выбор лучшего js-фреймворка не важен]

если смотреть на работу Django Templates отдельно от всего остального - ну, это та часть, которая сделана неплохо, она работает, если есть задача рендерить шаблоны на сервере (SSR), в самом деле, почему бы и не Django Templates или Jinja2, то есть если сделать некий микросервис или модуль, который бы занимался только рендерингом шаблонов и ничем больше и это было бы на Django Templates или Jinja2 - всё нормально, не так модно, но нормально) и тут тоже есть люди, которые считают, что вот Jinja2-то лучше, чем Django Templates, в данном контексте это тоже не важно)

тогда почему же Django Templates не стоит использовать и что подразумевают под этим люди, которые пропагандируют отказ от них? проблема в MVC, с таким подходом не получается красиво отделить данные от полученного в итоге html

то есть в Django можно разбить всё на приложения, и каждое приложение будет включать в себя генератор контекста с данными для подстановки в шаблоны и сами шаблоны... в этом и есть проблема, из-за которой так хочется агитировать против Django Templates... в современным мире более правильным считается подход, когда генерируется API, а рендеринг шаблонов - уже отдельно слабо связанный с этим сервис, то есть проблема не в самих Django Templates, а в том, как они прикручены, в том, как официальная документация предлагает их использовать... презензии к Django Templates на самом деле претензии к вот этой связке шаблонов с API, если бы можно было отдельно выделить все шаблоны и отдельно выделить все приложения и задеплоить их отдельно в рамках разных процессов, мб даже в разных контейнерах - тогда с SSR на сервере через Django templates в общем-то не было бы ничего плохого... наверное, кто-нибудь использует их именно так, но в 95% случаев говоря про Django Templates, подразумевают совсем другое, подразумевают вот этот старый MVC подход, который устарел

TL;DR: проблема не в Django Templates, а в том, как их обычно прикручивают

👍

я жму
а оно не жмется

в чем разница между проектом и приложением?

проект состоит из приложений

все равно не понятно

что делает проект, а что делает приложенька?

ага понял

у тебя есть сайт - это проект

на сайте есть
блог
галлерея
гостевая книга
форум
...

это приложения(аппки)
которые как правило друг с другом не связаны(но не всегда)

Т.е. лучше заполнять страницу, обращаясь к апи через js и так же через js вставлять полученные данные. Я правильно понял вашу мысль?

Просто пусть филиалы «стучат» в главный офис с нудной периодичностью.

Всегда связаны, если честно )

ну блог и форум мало связаны

Да, да это я то же думаю сделать команды и крон

А если все сделано по новомодному в джанге ddd, то вообще никогда не связаны

Этот пока не додумаются вынести обсуждение заметки блога в форуме.