Каталог решений - 1c + vis js(web app timeline)

Шаг 0. Зачем? Почему так?

Нужно было сделать:

1. работало быстро(не замороживало контекст пользователя, быстрый отклик)

2. было открыто для переиспользования в других инхаус поделках(фронт, бэк)

3. добавить фичи в которые штатная диаграмма не может(закраска на пересечении, выделить регламентированные фрагменты)

4. выглядело нормально

Технологический стэк:

1. 1с 8.3.8(3 сторона, источник событий)

2. ms sql(бд)

3. python 36(бэк)

4. js(фронт)

5. active x(фронт)

6. chromiumembedded(в статье особо не фигурирует, но он есть)(фронт)

Общая схемы работы:

бэкенд отвечает за данные, обрабатывает события об изменениях, инапп статистика, выполняет запросы в бд к view (with no lock)(ORM Model в этот раз), отдает актуальные данные(json, XML(XDTO), да тот самый который 1С понимает полностью и может после прогона через фабрику принять за свой объект(по этой части будет сказано ниже более подробно), можно отдавать например диаграмму Ганта целиком, что и было сделано)

1С изменяет данные(штатно)(условно ,проводит документы), триггерит в бэкенд, дергает методы фронт( обновить)

фронт( вм(то что исполняет код) chromium ) запрашивает из бэкенд данные, отрисовывает форму, обрабатывает события пользователя( отркыть, перетащить, удалить), триггерит в 1с(не обработка внешнего события!) при необходимости(сменить форму, изменить данные)

active x(фронт) — позволяет chromium(chromiumembedded) работать в IE(те еще раз, в ИЕ(тот что в 1с) работает chrome(chromiumembedded), с devtools и  отладкой из клиентского сеанса 1с и прочими своими функциями, и проблемами)

Шаг 1. Пишем backend.

Структура:

start.py — страртер

common\common.py — общие функции

common\external_record_log.py — основной модуль

common\ones_xml_types.py — модуль формирования xml(xdto)

common\orm\base.py — орм база(класс)

common\orm\fields.py — орм описание полей

common\orm\models.py — орм описание таблиц