Управляемая форма в 1С: чем она отличается от обычной

Управляемые и обычные формы — два разных поколения интерфейсной технологии платформы 1С:Предприятие. Обычные формы появились в версии 8.0 и рисуются разработчиком «вручную»: место каждого элемента, его размеры и поведение жёстко заданы в конфигураторе. Управляемые формы пришли с платформой 8.2 и работают по-другому: разработчик описывает только логическую структуру — реквизиты, команды, группы, — а внешний вид платформа строит сама под конкретный клиент.

Ключевое отличие не в оформлении, а в архитектуре. Обычная форма целиком живёт на клиенте: весь её код, включая обращения к базе данных, выполняется в одном процессе. Управляемая форма явно разделена на клиентскую и серверную части, и разработчик обязан сам управлять тем, где выполняется каждая процедура. Это меняет подход к написанию кода, к производительности и к организации обмена данными между клиентом и сервером.

Практически это означает следующее: обычная форма проста в освоении и удобна для быстрой отладки, но работает только в толстом клиенте и не запускается в веб-клиенте и мобильном клиенте. Управляемая форма требует более дисциплинированного программирования, зато один и тот же интерфейс работает в тонком, веб- и мобильном клиенте без переписывания. Все современные типовые конфигурации построены именно на управляемых формах.

Архитектурные различия: как устроена каждая форма

В обычной форме нет разделения контекстов. Модуль формы — это единая программа, которая выполняется на клиентском компьютере и имеет прямой доступ к объектам базы данных: можно написать запрос, создать объект документа, записать его — всё в одном обработчике. Такая модель интуитивно понятна, но порождает проблему: клиент постоянно обращается к базе, и при работе через медленный канал интерфейс «подвисает».

Управляемая форма существует одновременно в двух мирах. На клиенте живёт её визуальная часть и клиентские обработчики, на сервере — данные формы и серверные процедуры. Между ними платформа передаёт только изменённые данные, причём пакетно. Прямого доступа к базе из клиентского контекста нет: чтобы получить данные, нужно вызвать серверную процедуру.

Ещё одно принципиальное различие — декларативность. В обычной форме разработчик мышкой расставляет поля и кнопки по координатам. В управляемой форме элементы объединяются в группы, а платформа сама решает, как их отрисовать: в одну колонку на узком экране, в несколько — на широком. Поэтому управляемая форма адаптивна «из коробки», а обычная ломается при любом изменении разрешения.

Директивы компиляции и контексты выполнения

Главное, с чем сталкивается разработчик при переходе на управляемые формы, — директивы компиляции. Каждая процедура в модуле управляемой формы помечается одной из директив: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, &НаКлиентеНаСервереБезКонтекста. Платформа компилирует модуль несколько раз — отдельно для клиента и для сервера — и включает в каждый вариант только соответствующие процедуры.

В обычной форме ничего подобного нет: весь модуль компилируется один раз и работает на клиенте. Поэтому код из обычной формы нельзя просто скопировать в управляемую — обращения к объектам базы данных, запросы и конструкторы типа Документы.РеализацияТоваров.СоздатьДокумент() в клиентском контексте вызовут ошибку компиляции.

Типичный приём в управляемой форме — клиентский обработчик вызывает серверную процедуру, та выполняет запрос и возвращает простые данные (структуру, массив, таблицу значений). Серверные вызовы стоит минимизировать: каждый вызов — это сетевой обмен, и десяток мелких вызовов в цикле заметно замедлит форму. Правильный подход — собрать данные одним серверным вызовом.

&НаКлиенте
Процедура ЗаполнитьПоОстаткам(Команда)
    ЗаполнитьПоОстаткамНаСервере();
КонецПроцедуры

&НаСервере
Процедура ЗаполнитьПоОстаткамНаСервере()
    Запрос = Новый Запрос("ВЫБРАТЬ ...");
    // выполнение запроса и заполнение табличной части
КонецПроцедуры

Данные формы: реквизиты вместо объектов

В обычной форме элементы управления напрямую привязаны к объекту: табличное поле показывает табличную часть документа, поле ввода — реквизит справочника. Объект существует на клиенте в «боевом» виде, и его можно сразу записать вызовом Записать().

В управляемой форме основной объект преобразуется в специальные типы данных формы — ДанныеФормыСтруктура, ДанныеФормыКоллекция и другие. Это не объект базы данных, а его сериализуемое представление, которое можно передавать между клиентом и сервером. Чтобы записать объект, его нужно сначала преобразовать: РеквизитФормыВЗначение("Объект"), затем записать и при необходимости вернуть обратно через ЗначениеВРеквизитФормы.

Из этого следует важное ограничение: на клиенте в управляемой форме недоступны методы объектов базы данных, запросы, транзакции и прикладные типы вроде СправочникОбъект. Всё это — только на сервере. Зато на клиенте доступны диалоги, работа с файлами и оповещения, которых нет на сервере.

Сравнение по ключевым параметрам

Из таблицы видно, что управляемая форма выигрывает по масштабируемости и кроссплатформенности, а обычная — по простоте разработки. Именно поэтому в старых конфигурациях на обычных формах код часто компактнее, но перенести его на веб-клиент невозможно без полной переработки.

Модальность и асинхронность

В обычных формах широко используются модальные вызовы: Вопрос(), Предупреждение(), ОткрытьФормуМодально() останавливают выполнение кода до ответа пользователя. В управляемом приложении модальные окна запрещены на уровне режима совместимости современных конфигураций: веб-браузер в принципе не умеет приостанавливать выполнение скрипта, ожидая пользователя.

Вместо модальных вызовов применяются асинхронные аналоги с описанием оповещения: ПоказатьВопрос(), ПоказатьПредупреждение(), ОткрытьФорму() с обработчиком оповещения. Логика «спросить — получить ответ — продолжить» разбивается на две процедуры: одна показывает вопрос, вторая обрабатывает результат. Это требует перестройки мышления, но делает интерфейс отзывчивым.

Когда какой тип формы выбирать

Выбор по сути сделан за разработчика: режим совместимости конфигурации определяет, какие формы будут использоваться. В конфигурациях, работающих в режиме управляемого приложения, обычные формы просто не открываются. В старых конфигурациях на обычном приложении управляемые формы технически могут существовать, но запускаются только в толстом клиенте в особом режиме.

Обычные формы оправданы только в одном случае — поддержка унаследованной конфигурации, которая целиком построена на обычном приложении и не планирует миграцию. Для любой новой разработки, доработки типовых решений и тем более для работы через веб или на мобильных устройствах выбор однозначен — управляемые формы.

Как проверить, что форма работает правильно

После создания или доработки управляемой формы проверьте её в том клиенте, в котором будут работать пользователи. Форма, безупречная в толстом клиенте, может не открыться в веб-клиенте из-за модального вызова или неподдерживаемого метода. Минимальная проверка — запуск в тонком и веб-клиенте, открытие, заполнение, запись и закрытие формы.

Обратите внимание на скорость: если форма открывается заметно дольше пары секунд, ищите лишние серверные вызовы в обработчиках ПриОткрытии и ПриСозданииНаСервере. Замер производительности через технологический журнал или встроенный замер в конфигураторе покажет, какой вызов занимает время.

Частые вопросы