Когда появились управляемые формы в 1С и что это изменило

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

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

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

Когда именно появились управляемые формы

Технологическая платформа «1С:Предприятие 8.2» вышла в конце 2000-х годов и стала первой версией, где был реализован управляемый режим работы. Вместе с ней появились три ключевые новинки: управляемое приложение как новый режим запуска, тонкий клиент и веб-клиент, работающий через браузер без установки платформы на компьютер пользователя.

Платформа 8.2 не отменила обычные формы: они остались доступны для совместимости, и конфигурации, написанные под 8.1, продолжали работать в режиме обычного приложения. Это позволило предприятиям постепенно мигрировать, не переписывая весь код одномоментно. Однако все новые разработки фирма «1С» стала ориентировать на управляемый режим.

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

Чем управляемые формы отличаются от обычных

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

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

Третье отличие — работа с данными через реквизиты формы. Управляемая форма не имеет прямого доступа к объектам базы данных из клиентского кода. Данные объектов преобразуются в данные формы (например, ДанныеФормыСтруктура или ДанныеФормыКоллекция), а обратное преобразование выполняется на сервере при записи.

Зачем понадобилась новая модель форм

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

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

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

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

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

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

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

1. 1
   Откройте конфигуратор и выделите корень дерева конфигурации
2. 2
   Откройте палитру свойств и найдите «Основной режим запуска»
3. 3
   Проверьте значение: «Управляемое приложение» или «Обычное приложение»
4. 4
   Откройте любую форму документа и посмотрите модуль: директивы &НаКлиенте и &НаСервере подтверждают управляемую форму

Что изменилось для разработчика

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

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

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

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

&НаСервере
Процедура ПровестиДокументНаСервере()
    ДокОбъект = РеквизитФормыВЗначение("Объект");
    ДокОбъект.Записать(РежимЗаписиДокумента.Проведение);
    ЗначениеВРеквизитФормы(ДокОбъект, "Объект");
КонецПроцедуры

Обычные формы сегодня: когда они ещё встречаются

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

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

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

Как подойти к выбору режима для своей задачи

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

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

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

Частые вопросы об управляемых формах