Вопрос внутреннего устройства управляемых форм часто вызывает споры среди разработчиков. С одной стороны, мы видим интерфейс, работающий в браузере или тонком клиенте, что напоминает классическое веб-приложение. С другой стороны, механизмы 1С имеют свои уникальные особенности, связанные с типизацией, сессионностью и моделью данных. Рассмотрим подробно, как именно «под капотом» реализована работа управляемой формы, как код превращается в интерфейс и каким образом минимизируется трафик между клиентом и сервером.
Разберем, как исполняется код на встроенном языке 1С в различных клиентских средах. Вопреки распространенному мнению, платформа не переводит каждую строку кода в «чистый» JavaScript в реальном времени. Вместо этого используется интерпретатор байт-кода. Когда модуль компилируется, он превращается в платформенный полуфабрикат — байт-код.
Проанализируем работу веб-клиента: он представляет собой одно из крупнейших JavaScript-приложений (сотни тысяч строк кода), которое содержит в себе виртуальную машину. Эта машина загружает скомпилированный байт-код и исполняет его. Именно благодаря такому подходу работают модули, поставляемые «без исходных кодов» — клиент получает инструкции в виде байт-кода, которые интерпретатор успешно выполняет в браузере. В тонком клиенте процесс аналогичен, но там используется нативный код операционной системы.
Выясним, что происходит в памяти компьютера при открытии формы. Важно понимать, что форма существует в двух ипостасях: на сервере и на клиенте, но их состояния синхронизируются по требованию. Согласно официальной документации и логике работы платформы, процесс создания выглядит следующим образом:
СправочникОбъект или ДокументОбъект) считывается из базы данных в память сервера.ДанныеФормы. На этом этапе создается «серверная» часть формы.ДокументОбъект) удаляется из памяти сервера сразу после того, как данные были скопированы в реквизиты формы. Это критически важный момент: вне серверного вызова на сервере не существует «живого» объекта документа, только его данные в контексте формы.Рассмотрим пример того, как данные распределяются между клиентом и сервером. Реквизиты формы могут иметь типы, которые недоступны на клиенте. Например, реквизит с типом СправочникОбъект может существовать только на сервере. Если такой реквизит добавлен в форму, он будет «жить» в серверном контексте формы и будет доступен только при выполнении серверных процедур.
Одной из главных задач архитектуры управляемых форм является минимизация объема данных, передаваемых по сети. Для этого используется механизм отслеживания измененных данных (так называемый Dirty Checking). Посмотрим, как это работает на практике:
Когда пользователь меняет значение в поле ввода на клиенте, платформа помечает соответствующий элемент данных как «грязный» (измененный). При инициации серверного вызова (например, при нажатии кнопки, вызывающей процедуру &НаСервере), клиент отправляет не все данные формы, а только измененные значения («дельту»).
Сервер, получив эти изменения, обновляет свое состояние данных формы, выполняет программный код и, в свою очередь, возвращает на клиент только те данные, которые изменились в результате работы серверного алгоритма. Если мы программно изменим реквизит на сервере, платформа автоматически отправит его обратно клиенту для обновления интерфейса.
Пример кода, демонстрирующий контекстный вызов:
&НаКлиенте
Процедура КомандаВыполнить(Команда)
// Изменяем данные на клиенте
Объект.Комментарий = "Изменено на клиенте";
ВыполнитьДействиеНаСервере();
КонецПроцедуры
&НаСервере
Процедура ВыполнитьДействиеНаСервере()
// Платформа автоматически синхронизировала Объект.Комментарий
// Здесь мы можем работать с данными формы
Объект.Дата = ТекущаяДатаСеанса();
// После завершения процедуры Дата вернется на клиент
КонецПроцедуры
Архитектура 1С основана на декларативном описании интерфейса. Это означает, что сервер не посылает клиенту готовый HTML-код кнопок или таблиц. Вместо этого передается абстрактная структура: «здесь должна быть кнопка с таким-то именем, связанная с такой-то командой».
Клиентская часть движка самостоятельно отрисовывает элементы, используя нативные возможности среды. Именно поэтому форма выглядит как стандартное окно Windows в тонком клиенте и как веб-страница в браузере Safari на macOS, хотя описание формы в конфигураторе остается неизменным. Обмен данными происходит по протоколу HTTP/HTTPS, где данные упаковываются в специфический формат JSON (для веб-клиента) или сжатый бинарный формат (для тонкого клиента).
Важной частью архитектуры является работа с большими объемами данных в списках и таблицах. Проанализируем ситуацию: если в табличной части документа 10 000 строк, платформа никогда не передает их на клиент одновременно. Реализован механизм «окна» или виртуализации.
Клиент запрашивает только те строки, которые видны пользователю в данный момент, плюс небольшой буфер сверху и снизу. При скроллинге клиент динамически подгружает новые порции данных. Именно поэтому попытка перебора строк большой таблицы в цикле на клиенте может привести к множественным скрытым серверным вызовам и катастрофическому падению производительности. Для таких операций всегда следует использовать серверный контекст.
Многих разработчиков интересует вопрос: хранит ли сервер что-то между вызовами? Да, на сервере приложений существует сессионное хранилище. Хотя прикладные объекты уничтожаются, само состояние управляемой формы (значения её реквизитов) кешируется. Это позволяет платформе при следующем серверном вызове не перечитывать данные из базы и не пересоздавать форму с нуля, а быстро восстановить контекст из кеша. Однако для программиста это должно оставаться «черным ящиком» — мы должны проектировать код так, как будто между вызовами сервер ничего не знает о состоянии объектов, кроме того, что передано в данных формы.
Подводя итог, можно сказать, что управляемая форма — это высокоуровневая абстракция, которая берет на себя всю сложность клиент-серверного взаимодействия, позволяя разработчику сосредоточиться на бизнес-логике, используя привычный встроенный язык 1С.