Comments 15
Хочу начать с извинений, но не смог пройти мимо. Кровь из глаз до сих пор и нервный тик на сегодняшний день обеспечены. Неужели у вас там ни у кого глаз не дернулся? Столько ошибок в верстке макетов на фоне статьи про достижения на фронтенде - это просто какой-то испанский стыд
Или вот еще пример нового интерфейса вашего
Зато
ПриКликеSendREST
Смешно было бы, если бы не было так грустно(
Про первый скриншот — это редактор, там всё как есть — это так и надо. То есть как раз за счет этого редактора мы и находим косяки в верстке.
Про второй скрин, нового интерфейса — да, мы в курсе того, что там не выровнен текст под поле с кнопкой «найти». Это такой исторический казус. Благодаря этому казусу появились свойства и возможность отображать фоновые изображения в Группах элементов. Но на сайте на титульной странице этого еще не переделывали.
Ну и грустить не стоит, «ПриКликеSendREST» — для нас это решило проблему с наименованиями атрибутов.
Свой велосипед это хорошо.
До конца так и не понял, что из себя представляет решение.
Это программа на JavaScript, упакованная в Docker контейнер. Внутри много компонентов — элементов, внешними видом и поведением которых можно управлять через импортозамещенный Json. В основе Vue3, да и все остальное — это наш «какбЭфреймворк-Движок». Не только UI, но и UX. Это и обработка событий на элементах, и генерация запросов в формате «Импортозамещенного JSon» обратно в бэкенд.
Можно какие-нибудь подробности про возможности конфигурирования форм в плане например показа разного набора полей после выбора какого-нибудь значения поля, например после выбора типа клиента для физ. и юр. лиц показывать разные наборы атрибутов. Как сделана валидация?
В Атом.Форме есть сущности — Элемент Формы, Данные, Действие.
Элемент формы — это то, что видно на экране с каким-то дизайн-оформлением. Есть блок, связанный с так называемым «Условным оформлением». Это набор правил, при срабатывании которых Атом.Форма самостоятельно меняет Оформление, Видимость, Доступность, Редактибельность и т. д. Можно прислать заранее все поля, и показывать или не показывать их в зависимости от Данных. Это первый способ интерактивного изменения формы без обмена с бэкендом.
У каждого элемента могут быть разные события. Для события описываются действия, которые надо выполнить. Есть Действия-Команды, которые отправляются в бэкенд, а есть «ПредопределенныеДействия», и тогда можно при нажатии на кнопку выполнить команду «ДобавитьЭлементФормы» или «ОбновитьДанныеФормы». Предопределенные действия это второй способ интерактивности.
Эти же команды могут прилететь в ответе от бэкенда на Действие-Команду. Это третий способ добавить интерактивности и динамичности в формы.
На примере ниже — пример описания действия запроса бэкенду.
{
"ЭлементыФормы": [
{
"ТипЭлемента": "Кнопка",
"Оформление": {
"ЦветФона": "primary"
},
"ПутьКДанным": "КлючКHashMap-е-НазваниеУсловноеДляПримера",
"Действие": {
"Команда": "GetAction",
"ПараметрыДействия": {
},
"ПередаватьКонтекст": [
"КлючКHashMap-е-НазваниеУсловноеДляПримера"
]
}
}
],
"Данные": {
"КлючКHashMap-е-НазваниеУсловноеДляПримера": "Какое-то-значение"
}
}
Импортозамещенный Json - ах, звучит как песня !
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Архитектура решения воспроизводит 1С подходы. Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга? Или это больше поверхностная копия на самостоятельном размышлении и наблюдении? Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы. Вы до этих файлов тоже добрались, например?
Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора? Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?
Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.
Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы? Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему? Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям? Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?
Спасибо за вопросы! Постараюсь ответить подробно.
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга?
Или это больше поверхностная копия на самостоятельном размышлении и наблюдении?
В реализацию веб-клиента мы не погружались, даже реверс-инжиниринга не было. Мы посмотрели, что он может, и поняли, что нам «так не годится». Причина проста: веб-клиент 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С нельзя скачать, установить и запустить отдельно и в самостоятельном докер-контейнере без платформы 1С. Могу быть не прав, не большой специалист в 1С.
Но более всего интересно, почему Вы не рассматривали технологию 1С Элемент, которая как раз и предназдачена для описанного в статье кейса, как по самой технологии, так и по политике лицензирования?
Да, спасибо за вопрос, он ожидаемый.
Когда мы начинали проект и уже даже сделали MVP в 2021 году, 1С:Элемент был только анонсирован. В публичный доступ его выложили чуть ли не в декабре 2024 года. Мы на тот момент уже второй год как были в продуктиве.
Сказать по версиям 1С:Платформы мы не можем, нам нужны сертифицированные решения по понятным причинам. Заставить все бэкенды пользоваться 1С:Элемент мы тоже не можем. Атом.Форма это универсальный вебклиент для любого бэкенда на любой технологической платформе.
Импортозамещённый JSON
Некачественно. Булево значение до сих пор латиницей, а цифры - арабские
изобрели конструктор web-форм в 2025-м году, норм
Фронт без бэка: как мы сумели собрать тысячу форм в одну систему и не потерять рассудок