Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей. Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга? Или это больше поверхностная копия на самостоятельном размышлении и наблюдении?
В реализацию веб-клиента мы не погружались, даже реверс-инжиниринга не было. Мы посмотрели, что он может, и поняли, что нам «так не годится». Причина проста: веб-клиент 1С привязан к 1С на бэкенде. А у нас мало того, что бэкендов несколько, так они еще и не все на 1С.
Первый «подход к штанге» — попытка ускорить верстку форм на основе «толстого» платформенного клиента. Бэкендеры написали кусочек кода на 1С, который который обходил форму 1С и выгружал в JSON. А так как в 1С почти все термины на русском («Кнопка», «ПолеВвода», «ЦветФона», «Оформление», «ГруппировкаПоГоризонталиЕслиВозможно»), то и не стали изобретать маппинга с русского на английский. Сэкономили массу времени. Да и сейчас экономим.
Мы довольно быстро ушли от варианта «а давайте дальше использовать платформенный 1С как инструмент разработки форм и переносить его фичи». Когда интерфейс переехал в браузер, появилась масса хотелок, которые 1С реализовать не мог.
Итог: Атом.Форм — это полностью самостоятельный продукт, а не копия веб-клиента 1С. Названия некоторых базовых элементов и свойств остались из 1С как реверанс в сторону бэкенд-разработчиков.
Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы. Вы до этих файлов тоже добрались, например?
Не добрались, да и не нужно было.
Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора?
Да, поначалу это выглядело необычно и даже непривычно. Особенно для тех, кто работает на Java или C++. Мы даже сделали DTO и были готовы все попереводить (например, Button вместо «Кнопка»). Но к нашему большому удивлению бекендерам стало проще ставить задачи «Добавить в ТаблицуФормы свойство ЦветФонаЗаголовкаКолонки». Собственно это вся постановка, лакончиная и самодостаточная.
Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?
На этапе поиска решения пробовали разные форматы: от QML до YAML. Вкратце — не прижилось. Но JSON оказался оптимальным для браузеров, а к структуре и названиям быстро привыкли.
Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.
Рассматривали, но победил Vue. Тут и исторические причины, и то что разработчиков на Vue подобрать проще. Сейчас, когда фронт полностью отделен от бэкенда, мы вольны выбирать любую реализацию — хоть ReactJS, хоть Flutter, хоть собственный АтомJS фреймворк.
Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы? Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему? Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям?
Бекенду необходимо реализовать обработчик для событий которые считаются «бекендными». Например, обрабатывать изменение ширины колонки или ее перемещение мышью не нужно. Но если прилетит запрос «СохранитьНастройкиТаблицы» — такой метод бэкенду придется написать.
Кроме того, функциональные действия вроде заполнения выпадающих списков данными — это тоже задача бэкенда. У 1С для таких целей есть несколько реализаций прослоек.
Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?
И такой вариант есть, с него как я выше написал начинали. Для каких-то форм он годится. Со временем стало понятно что возможности в браузере гораздо шире, чем у «нативного» конструктора 1С. Со временем мы это ощутили и переключились на новый подход.
"в 1С, например, есть свой инструмент по вёрстке клиентской формы." И далее у вас идет скриншот платформенного редактора формы.
Все верно, платформенного редактора формы 1С.
Но 1С всем клиентам не поставишь, это практически невыполнимо. Думаю, под "не поставишь", Вы имелли виду "это слишком дорого в деньгах"? Ставить веб-клиент не нужно, Вам это и так известно.
Да конечно, в курсе что ставить вебклиент не нужно. Имелось ввиду «платформенного клиента 1С всем не поставишь».
А вебклиент 1С нам не подошел потому что не все бэкенды на 1С. Насколько я знаю, вебклиент 1С нельзя скачать, установить и запустить отдельно и в самостоятельном докер-контейнере без платформы 1С. Могу быть не прав, не большой специалист в 1С.
Но более всего интересно, почему Вы не рассматривали технологию 1С Элемент, которая как раз и предназдачена для описанного в статье кейса, как по самой технологии, так и по политике лицензирования?
Да, спасибо за вопрос, он ожидаемый.
Когда мы начинали проект и уже даже сделали MVP в 2021 году, 1С:Элемент был только анонсирован. В публичный доступ его выложили чуть ли не в декабре 2024 года. Мы на тот момент уже второй год как были в продуктиве.
Сказать по версиям 1С:Платформы мы не можем, нам нужны сертифицированные решения по понятным причинам. Заставить все бэкенды пользоваться 1С:Элемент мы тоже не можем. Атом.Форма это универсальный вебклиент для любого бэкенда на любой технологической платформе.
В Атом.Форме есть сущности — Элемент Формы, Данные, Действие.
Элемент формы — это то, что видно на экране с каким-то дизайн-оформлением. Есть блок, связанный с так называемым «Условным оформлением». Это набор правил, при срабатывании которых Атом.Форма самостоятельно меняет Оформление, Видимость, Доступность, Редактибельность и т. д. Можно прислать заранее все поля, и показывать или не показывать их в зависимости от Данных. Это первый способ интерактивного изменения формы без обмена с бэкендом.
У каждого элемента могут быть разные события. Для события описываются действия, которые надо выполнить. Есть Действия-Команды, которые отправляются в бэкенд, а есть «ПредопределенныеДействия», и тогда можно при нажатии на кнопку выполнить команду «ДобавитьЭлементФормы» или «ОбновитьДанныеФормы». Предопределенные действия это второй способ интерактивности.
Эти же команды могут прилететь в ответе от бэкенда на Действие-Команду. Это третий способ добавить интерактивности и динамичности в формы.
На примере ниже — пример описания действия запроса бэкенду.
До конца так и не понял, что из себя представляет решение.
Это программа на JavaScript, упакованная в Docker контейнер. Внутри много компонентов — элементов, внешними видом и поведением которых можно управлять через импортозамещенный Json. В основе Vue3, да и все остальное — это наш «какбЭфреймворк-Движок». Не только UI, но и UX. Это и обработка событий на элементах, и генерация запросов в формате «Импортозамещенного JSon» обратно в бэкенд.
Про первый скриншот — это редактор, там всё как есть — это так и надо. То есть как раз за счет этого редактора мы и находим косяки в верстке.
Про второй скрин, нового интерфейса — да, мы в курсе того, что там не выровнен текст под поле с кнопкой «найти». Это такой исторический казус. Благодаря этому казусу появились свойства и возможность отображать фоновые изображения в Группах элементов. Но на сайте на титульной странице этого еще не переделывали.
Ну и грустить не стоит, «ПриКликеSendREST» — для нас это решило проблему с наименованиями атрибутов.
Спасибо за вопросы! Постараюсь ответить подробно.
В реализацию веб-клиента мы не погружались, даже реверс-инжиниринга не было. Мы посмотрели, что он может, и поняли, что нам «так не годится». Причина проста: веб-клиент 1С привязан к 1С на бэкенде. А у нас мало того, что бэкендов несколько, так они еще и не все на 1С.
Первый «подход к штанге» — попытка ускорить верстку форм на основе «толстого» платформенного клиента. Бэкендеры написали кусочек кода на 1С, который который обходил форму 1С и выгружал в JSON. А так как в 1С почти все термины на русском («Кнопка», «ПолеВвода», «ЦветФона», «Оформление», «ГруппировкаПоГоризонталиЕслиВозможно»), то и не стали изобретать маппинга с русского на английский. Сэкономили массу времени. Да и сейчас экономим.
Мы довольно быстро ушли от варианта «а давайте дальше использовать платформенный 1С как инструмент разработки форм и переносить его фичи». Когда интерфейс переехал в браузер, появилась масса хотелок, которые 1С реализовать не мог.
Итог: Атом.Форм — это полностью самостоятельный продукт, а не копия веб-клиента 1С. Названия некоторых базовых элементов и свойств остались из 1С как реверанс в сторону бэкенд-разработчиков.
Не добрались, да и не нужно было.
Да, поначалу это выглядело необычно и даже непривычно. Особенно для тех, кто работает на Java или C++. Мы даже сделали DTO и были готовы все попереводить (например, Button вместо «Кнопка»). Но к нашему большому удивлению бекендерам стало проще ставить задачи «Добавить в ТаблицуФормы свойство ЦветФонаЗаголовкаКолонки». Собственно это вся постановка, лакончиная и самодостаточная.
На этапе поиска решения пробовали разные форматы: от QML до YAML. Вкратце — не прижилось. Но JSON оказался оптимальным для браузеров, а к структуре и названиям быстро привыкли.
Рассматривали, но победил Vue. Тут и исторические причины, и то что разработчиков на Vue подобрать проще. Сейчас, когда фронт полностью отделен от бэкенда, мы вольны выбирать любую реализацию — хоть ReactJS, хоть Flutter, хоть собственный АтомJS фреймворк.
Бекенду необходимо реализовать обработчик для событий которые считаются «бекендными». Например, обрабатывать изменение ширины колонки или ее перемещение мышью не нужно. Но если прилетит запрос «СохранитьНастройкиТаблицы» — такой метод бэкенду придется написать.
Кроме того, функциональные действия вроде заполнения выпадающих списков данными — это тоже задача бэкенда. У 1С для таких целей есть несколько реализаций прослоек.
И такой вариант есть, с него как я выше написал начинали. Для каких-то форм он годится. Со временем стало понятно что возможности в браузере гораздо шире, чем у «нативного» конструктора 1С. Со временем мы это ощутили и переключились на новый подход.
Все верно, платформенного редактора формы 1С.
Да конечно, в курсе что ставить вебклиент не нужно. Имелось ввиду «платформенного клиента 1С всем не поставишь».
А вебклиент 1С нам не подошел потому что не все бэкенды на 1С. Насколько я знаю, вебклиент 1С нельзя скачать, установить и запустить отдельно и в самостоятельном докер-контейнере без платформы 1С. Могу быть не прав, не большой специалист в 1С.
Да, спасибо за вопрос, он ожидаемый.
Когда мы начинали проект и уже даже сделали MVP в 2021 году, 1С:Элемент был только анонсирован. В публичный доступ его выложили чуть ли не в декабре 2024 года. Мы на тот момент уже второй год как были в продуктиве.
Сказать по версиям 1С:Платформы мы не можем, нам нужны сертифицированные решения по понятным причинам. Заставить все бэкенды пользоваться 1С:Элемент мы тоже не можем. Атом.Форма это универсальный вебклиент для любого бэкенда на любой технологической платформе.
В Атом.Форме есть сущности — Элемент Формы, Данные, Действие.
Элемент формы — это то, что видно на экране с каким-то дизайн-оформлением. Есть блок, связанный с так называемым «Условным оформлением». Это набор правил, при срабатывании которых Атом.Форма самостоятельно меняет Оформление, Видимость, Доступность, Редактибельность и т. д. Можно прислать заранее все поля, и показывать или не показывать их в зависимости от Данных. Это первый способ интерактивного изменения формы без обмена с бэкендом.
У каждого элемента могут быть разные события. Для события описываются действия, которые надо выполнить. Есть Действия-Команды, которые отправляются в бэкенд, а есть «ПредопределенныеДействия», и тогда можно при нажатии на кнопку выполнить команду «ДобавитьЭлементФормы» или «ОбновитьДанныеФормы». Предопределенные действия это второй способ интерактивности.
Эти же команды могут прилететь в ответе от бэкенда на Действие-Команду. Это третий способ добавить интерактивности и динамичности в формы.
На примере ниже — пример описания действия запроса бэкенду.
Это программа на JavaScript, упакованная в Docker контейнер. Внутри много компонентов — элементов, внешними видом и поведением которых можно управлять через импортозамещенный Json. В основе Vue3, да и все остальное — это наш «какбЭфреймворк-Движок». Не только UI, но и UX. Это и обработка событий на элементах, и генерация запросов в формате «Импортозамещенного JSon» обратно в бэкенд.
Про первый скриншот — это редактор, там всё как есть — это так и надо. То есть как раз за счет этого редактора мы и находим косяки в верстке.
Про второй скрин, нового интерфейса — да, мы в курсе того, что там не выровнен текст под поле с кнопкой «найти». Это такой исторический казус. Благодаря этому казусу появились свойства и возможность отображать фоновые изображения в Группах элементов. Но на сайте на титульной странице этого еще не переделывали.
Ну и грустить не стоит, «ПриКликеSendREST» — для нас это решило проблему с наименованиями атрибутов.