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

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

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

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

Как устроена обычная форма и в каком режиме она работает

Обычная форма создаётся визуальным конструктором, где разработчик вручную размещает элементы на форме: поля ввода, табличные поля, кнопки. Координаты, привязки и размеры задаются явно. Модуль формы выполняется на клиенте, и из него доступны и элементы формы, и данные объекта напрямую — например, можно обратиться к реквизиту документа через ДокументОбъект или через данные формы без какого-либо разделения контекстов.

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

Типичный сценарий, где обычные формы ещё встречаются, — старые конфигурации вроде «Управление производственным предприятием 1.3» или самописные решения, созданные до массового перехода на платформу 8.2–8.3. Пока такая конфигурация не переведена на управляемое приложение, пользователи вынуждены работать через толстый клиент, что ограничивает удалённый доступ и публикацию базы через веб-сервер.

Как устроена управляемая форма

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

Данные формы хранятся в реквизитах формы, а не в элементах. Основной реквизит (например, «Объект» для формы документа) представляет собой данные объекта, сериализованные в специальный формат. На клиенте доступна только «проекция» этих данных — изменить объект базы напрямую нельзя, для записи нужен серверный вызов.

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

Разделение кода на клиентский и серверный

Это самое трудное отличие для тех, кто переходит с обычных форм. В обычной форме можно было в одном обработчике нажатия кнопки и изменить элементы на форме, и записать объект в базу. В управляемой форме такой код не скомпилируется: клиентский обработчик не имеет доступа к объектам базы и к большинству прикладных типов.

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

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

&НаСервере
Процедура ЗаполнитьЦеныНаСервере()
    // Здесь доступны запросы и прикладные объекты
КонецПроцедуры

Директива &НаСервереБезКонтекста используется, когда серверной процедуре не нужны данные формы: она получает параметры и возвращает результат. Такие вызовы дешевле, потому что платформа не сериализует весь контекст формы туда и обратно. Для тяжёлых операций с данными формы применяют методы РеквизитФормыВЗначение() и ЗначениеВРеквизитФормы().

Сравнение ключевых характеристик

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

Как определить, какие формы используются в конфигурации

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

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

Миграция с обычных форм на управляемые

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

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

1. 1
   Создайте управляемую форму объекта в конфигураторе
2. 2
   Перенесите данные в реквизиты формы и настройте элементы
3. 3
   Разделите код: интерфейс — на клиенте, работа с базой — на сервере
4. 4
   Проверьте форму в тонком клиенте и в веб-клиенте
5. 5
   Удалите или отключите старую обычную форму после приёмки

Типичные ошибки при работе с управляемыми формами

Отдельная группа ошибок связана с производительностью. Управляемая форма при каждом серверном вызове с контекстом передаёт данные формы на сервер и обратно. Если форма содержит большие табличные части, такие вызовы становятся заметно дорогими. Оптимизация сводится к сокращению числа вызовов, использованию &НаСервереБезКонтекста и переносу тяжёлой логики в общие модули.

Что выбрать для новой разработки

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

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