Разработка и Конфигурация · 12 мин
Чем отличаются обычные формы от управляемых в 1С
Чем отличаются обычные формы от управляемых в 1С: принципы работы, клиент-серверное взаимодействие, код, совместимость и критерии выбора для разработки.
Обычные и управляемые формы — это два поколения механизма построения пользовательского интерфейса в платформе 1С:Предприятие. Обычные формы появились в платформе 8.0 и 8.1, а управляемые были введены в версии 8.2 и стали основным подходом в 8.3. Разница между ними — не косметическая, а архитектурная: меняется сам принцип взаимодействия клиента и сервера, способ описания интерфейса и модель программирования.
Главная идея управляемых форм — декларативность и разделение исполнения кода между клиентом и сервером. Разработчик описывает, что должно быть на форме, а платформа сама решает, как это отрисовать в тонком клиенте, веб-клиенте или мобильном приложении. В обычных формах разработчик вручную размещал каждый элемент, а вся логика выполнялась на клиенте, что делало невозможной работу через веб-браузер.
Понимание отличий важно на практике в трёх ситуациях: при доработке старых конфигураций (УПП, УТ 10.3), где используются обычные формы; при разработке новых решений, где стандарт — управляемые формы; и при миграции конфигураций с обычного интерфейса на управляемый. Ниже разберём отличия по каждому аспекту и критерии выбора.
Принцип построения интерфейса: ручная разметка против декларативного описания
В обычной форме разработчик в редакторе формы размещает каждый элемент вручную: кнопки, поля ввода, табличные части, надписи. Координаты, размеры и привязки задаются явно. Платформа отображает форму ровно так, как её нарисовали, — по сути это классический подход «конструктора окна», знакомый по десктопным средам разработки.
В управляемой форме разработчик не рисует интерфейс, а описывает его структуру: какие реквизиты выводить, в какие группы объединить, какие команды доступны. Платформа сама компонует элементы на экране с учётом устройства, разрешения и настроек. Один и тот же документ будет выглядеть по-разному в тонком клиенте на мониторе и в мобильном клиенте на смартфоне — без дополнительной работы программиста.
Практическое следствие: в управляемых формах нельзя «прибить» кнопку к конкретной координате. Попытки перенести привычки из обычных форм — например, точное позиционирование элементов — приводят к борьбе с платформой. Правильный подход — мыслить группами, порядком элементов и вариантами отображения.
Модель исполнения кода: клиент и сервер
Это самое глубокое отличие. В обычных формах весь код модуля формы выполняется на клиенте (в толстом клиенте, который имеет прямой доступ к базе данных). Запросы к данным, проведение документов, сложные вычисления — всё происходит в одном контексте, и разработчик не задумывается о границах между клиентом и сервером.
В управляемой форме код строго разделён. Директивы компиляции определяют, где выполняется каждая процедура:
&НаКлиенте
Процедура КомандаРассчитать(Команда)
РассчитатьНаСервере();
КонецПроцедуры
&НаСервере
Процедура РассчитатьНаСервере()
// запросы к базе данных, работа с объектами
КонецПроцедуры
Каждый вызов сервера из клиентского контекста — это сетевое обращение. Частые «короткие» серверные вызовы в цикле заметно замедляют форму, особенно через веб-клиент или медленный канал. Поэтому в управляемых формах принято собирать данные пакетно: один серверный вызов, который делает всю тяжёлую работу и возвращает готовый результат.
Работа с данными формы
В обычной форме реквизиты объекта доступны напрямую: можно обратиться к табличной части документа, перебрать строки, изменить значения — всё в едином контексте. Типы данных на форме и в базе совпадают, что упрощает код, но смешивает представление и данные.
В управляемой форме данные представлены специальными типами: ДанныеФормыСтруктура, ДанныеФормыКоллекция, ДанныеФормыДерево. На сервере их можно преобразовать в прикладные объекты методом РеквизитФормыВЗначение(), выполнить операции и вернуть обратно через ЗначениеВРеквизитФормы(). Это добавляет кода, но обеспечивает чёткую границу между представлением и базой данных.
Ещё одно следствие: в управляемой форме на клиенте недоступны многие серверные типы (например, Запрос, СправочникОбъект). Попытка использовать их в клиентском контексте приведёт к ошибке компиляции — платформа контролирует это на этапе проверки модуля.
Поддерживаемые клиенты и режимы запуска
| Параметр | Обычные формы | Управляемые формы |
|---|---|---|
| Толстый клиент | Поддерживается | Поддерживается |
| Тонкий клиент | Не поддерживается | Поддерживается |
| Веб-клиент | Не поддерживается | Поддерживается |
| Мобильный клиент | Не поддерживается | Поддерживается |
| Позиционирование элементов | Ручное, по координатам | Автоматическое, по структуре |
| Модель кода | Весь код на клиенте | Разделение клиент/сервер |
| Данные формы | Прямой доступ к объекту | Специальные типы данных формы |
Ограничение обычных форм толстым клиентом — главная причина, по которой они считаются устаревшими. Тонкий и веб-клиенты позволяют работать с базой через интернет без установки тяжёлого приложения, а мобильный клиент — со смартфонов. Конфигурация, построенная на обычных формах, лишена всех этих возможностей.
При этом платформа сохраняет обратную совместимость: конфигурацию в режиме обычного приложения можно запускать и в современных версиях. Но режим совместимости ограничивает использование новых механизмов платформы, поэтому «замораживать» систему на старом режиме — осознанный технический долг.
Командный интерфейс и «Такси»
Обычные формы работают в классическом интерфейсе с меню и панелями инструментов, знакомом по конфигурациям вроде УТ 10.3 или УПП 1.3. Управляемые формы работают в интерфейсе «Такси» (и ранее — в интерфейсе версии 8.2), где навигация строится по подсистемам, а панели разделов, функций и избранного формируются автоматически.
Интерфейс «Такси» доступен только в управляемом режиме. Если конфигурация запускается в режиме обычного приложения, современный интерфейс включить нельзя. Это ещё один аргумент при убеждении руководства в необходимости перевода старой конфигурации на управляемые формы: пользователи получают заметно более удобную навигацию.
Когда какие формы использовать на практике
Выбор фактически определяется конфигурацией, с которой вы работаете. В типовых решениях на управляемом приложении (УТ 11, ERP, БП 3.0, ЗУП 3.1) новые объекты создаются только с управляемыми формами. В старых конфигурациях на обычном приложении новые формы по умолчанию создаются обычными — и менять это внутри одной системы без полной миграции не имеет смысла.
Как выбрать тип формы
Смешанный вариант тоже существует: конфигурация в режиме управляемого приложения может содержать отдельные обычные формы, если разрешён режим совместимости. Но такие «островки» усложняют поддержку и путают пользователей разным поведением окон, поэтому их стоит считать временным решением на период миграции.
Миграция с обычных форм на управляемые
Автоматической конвертации форм «в один клик» не существует: различия моделей слишком глубоки. Реальный путь — поэтапный перенос: сначала конфигурация переводится в режим управляемого приложения, затем наиболее используемые формы переписываются вручную, а редкие переносятся в последнюю очередь или остаются обычными на время.
- 1Сделайте резервную копию информационной базы и выгрузку конфигурации
- 2Изучите, какие формы реально используются пользователями, и составьте приоритетный список
- 3Переведите конфигурацию в режим управляемого приложения в свойствах конфигурации
- 4Настройте подсистемы и командный интерфейс для навигации в «Такси»
- 5Переписывайте формы по приоритету: сначала декларативная структура, затем разделение кода на клиент и сервер
- 6Проверяйте каждую форму в тонком клиенте и исправляйте ошибки компиляции модулей
- 7После переноса ключевых форм проведите тестирование основных сценариев работы пользователей
Самая трудоёмкая часть — переработка кода модулей. Логику, которая в обычной форме работала «в одну строку» с объектом, приходится переносить в серверные процедуры, а обращения к элементам формы — приводить к новой модели данных. На больших формах (например, сложные документы с десятком табличных частей) это может занимать заметное время даже у опытного разработчика.
Как проверить результат после переноса формы
Перенесённая форма считается рабочей, если она открывается и корректно функционирует во всех целевых клиентах, а не только в том, где велась разработка. Минимальная проверка — открытие формы списка и формы объекта, создание и запись нового элемента, выполнение основных команд формы.
Контрольные точки после переноса формы
Форма открывается без ошибок, элементы отображаются корректно
Ошибки компиляции модуля или пустая форма
Данные сохраняются, движения формируются как раньше
Ошибки при записи, потеря данных табличных частей
Отклик на действия пользователя без заметных пауз
Задержки из-за частых серверных вызовов в циклах
Форма функционирует так же, как в тонком клиенте
Недоступные функции или ошибки, специфичные для браузера
Отдельно стоит проверить поведение формы при малой ширине окна: управляемые формы перестраиваются автоматически, и важно убедиться, что группы сжимаются осмысленно, а ключевые кнопки не «уезжают» за пределы видимости. Это настраивается свойствами групп, а не координатами.
Что важно запомнить
Обычные формы — ручная отрисовка интерфейса и весь код на клиенте, работают только в толстом клиенте. Управляемые формы — декларативная структура, разделение кода на клиент и сервер, поддержка тонкого, веб- и мобильного клиентов. Новая разработка ведётся на управляемых формах; обычные встречаются в старых конфигурациях и требуют планомерной миграции.
Частые вопросы
Можно ли открыть обычную форму в тонком клиенте?
Нет. Обычные формы работают только в толстом клиенте, запущенном в режиме обычного приложения. Если требуется доступ через тонкий или веб-клиент, форму нужно переписывать как управляемую.
Почему код из обычной формы не работает после копирования в управляемую?
В управляемой форме код разделён на клиентский и серверный контексты. Обращения к объектам базы данных, запросам и многим типам недоступны на клиенте. Такой код нужно переносить в серверные процедуры и адаптировать под типы данных формы.
Что означают директивы &НаКлиенте и &НаСервере?
Это директивы компиляции, указывающие платформе, где будет исполняться процедура. &НаКлиенте — в контексте клиентского приложения, &НаСервере — на сервере 1С. Вариант &НаСервереБезКонтекста используется для процедур, которым не нужны данные конкретной формы, что экономит ресурсы при вызове.
Нужно ли срочно переводить старую конфигурацию на управляемые формы?
Срочности нет: платформа поддерживает режим обычного приложения. Но если требуется работа через браузер, мобильные устройства, публикация базы в облаке или использование новых механизмов платформы, миграция становится необходимой. Планировать её лучше заранее, поэтапно.
Можно ли в одной конфигурации использовать оба типа форм?
Технически да, если в свойствах конфигурации разрешён соответствующий режим совместимости. Однако это считается временным решением на период миграции: пользователи получают разнородный интерфейс, а поддержка двух моделей усложняет разработку.
Где посмотреть, в каком режиме работает конфигурация?
В конфигураторе откройте свойства корневого узла конфигурации и найдите параметр «Основной режим запуска» и «Режим совместимости». Также режим виден при запуске: обычное приложение имеет классическое меню, управляемое — интерфейс «Такси» с панелью разделов.