Переход от обычных форм 1С к управляемым формам — это не просто обновление интерфейса, а фундаментальное изменение архитектуры приложения. Многие разработчики, привыкшие к парадигме обычных форм, задаются вопросом: существует ли автоматический конвертер для такого перехода? Важно сразу отметить: прямого, автоматического инструмента для преобразования обычных форм в управляемые в 1С не предусмотрено. Это объясняется глубинными различиями в подходах к разработке, принципах работы клиент-серверного взаимодействия и управлению пользовательским интерфейсом. Следовательно, процесс миграции по большей части подразумевает ручное пересоздание форм и тщательную адаптацию всей связанной логики. Давайте разберем этот процесс подробно, рассматривая ключевые аспекты и рекомендации.
Основной и наиболее правильный путь для перевода формы из обычной в управляемую — это её полное ручное пересоздание в конфигураторе. Мы будем использовать новый конструктор форм и переносить функционал, соблюдая принципы управляемого приложения. Этот подход требует глубокого понимания принципов работы платформы 1С:Предприятие 8 в режиме управляемого приложения и соблюдения ряда архитектурных особенностей.
Понимание и реализация разделения клиент-серверного кода: Ключевой аспект миграции
Одним из наиболее значимых отличий управляемых форм является строгая регламентация места выполнения кода. В обычных формах большая часть кода могла выполняться на клиенте, даже если она взаимодействовала с базой данных. В управляемых формах это разделение является краеугольным камнем архитектуры. Мы должны тщательно анализировать каждую строчку старого кода и определять, к какому слою она относится.
&НаКлиенте: Клиентский контекст выполнения.
Код, помеченный этой директивой, исполняется непосредственно на стороне клиента. Это может быть компьютер пользователя, тонкий клиент, веб-браузер или мобильное устройство. К клиентскому коду относятся все операции, связанные с непосредственным взаимодействием с пользователем и управлением элементами формы: отображение сообщений, изменение видимости или доступности элементов, перерисовка интерфейса, выполнение простых арифметических операций или форматирование строк, которые не требуют обращения к данным информационной базы. Например, обработка нажатия кнопки, проверка заполнения поля формы без обращения к справочникам, или изменение цвета элемента формы будут выполняться на клиенте.
&НаСервере: Серверный контекст выполнения.
Код, помеченный директивой &НаСервере, исполняется на сервере 1С:Предприятия. Это критически важно для выполнения всей бизнес-логики, которая требует доступа к данным информационной базы. Сюда относится чтение, запись, изменение объектов базы данных (справочников, документов, регистров), выполнение запросов, сложные расчеты, работа с внешними интеграциями. При вызове серверной процедуры с клиента (например, из клиентской процедуры или обработчика события), контекст формы (т.е., все данные, которые видны в форме, её реквизиты) автоматически передается на сервер. Это позволяет серверной процедуре работать с актуальным состоянием формы, что очень удобно для сохранения данных или их первичной обработки.
&НаСервереБезКонтекста: Серверный контекст без передачи контекста формы.
Эта директива также указывает на выполнение кода на сервере, но с одним важным отличием: контекст формы на сервер не передается. Это означает, что процедура не имеет прямого доступа к реквизитам формы и её элементам. Используется для выполнения фоновых задач, вспомогательных серверных операций, общих функций, которые не зависят от конкретного состояния формы. Такие вызовы являются более производительными, так как объем передаваемых данных между клиентом и сервером минимален. Мы будем использовать &НаСервереБезКонтекста, когда нам нужно выполнить операцию на сервере, не связанную с текущим состоянием формы, например, получить некие общие данные или выполнить фоновую обработку.
При переработке форм, мы столкнемся с необходимостью рефакторинга практически всех процедур и функций. Вся логика, которая раньше могла выполняться на клиенте, но при этом затрагивала базу данных или была ресурсоемкой, должна быть перенесена на сервер. Рассмотрим типовой пример из обычной формы, где код мог бы выглядеть так:
// В обычной форме - это мог быть обработчик кнопки "Провести"
Процедура КомандаПровести(Кнопка)
Если Объект.Сумма > 1000 Тогда
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| Документ.РеализацияТоваровУслуг.Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг КАК ДокументРеализацияТоваровУслуг
|ГДЕ
| ДокументРеализацияТоваровУслуг.СуммаДокумента > &МинимальнаяСумма";
Запрос.УстановитьПараметр("МинимальнаяСумма", 1000);
Выборка = Запрос.Выполнить().Выбрать();
Сообщить("Найдено документов с большой суммой:");
Пока Выборка.Следующий() Цикл
Сообщить(Выборка.Ссылка);
КонецЦикла;
Объект.Провести(); // Проведение документа
Иначе
Сообщить("Сумма документа недостаточна для выполнения специальной обработки.");
КонецЕсли;
КонецПроцедура
В управляемой форме такой код будет разделен. Условие проверки Объект.Сумма и сообщение пользователю могут остаться на клиенте, но весь запрос к базе данных, его обработка и проведение документа должны быть вынесены в серверную процедуру:
// В модуле формы на клиенте
&НаКлиенте
Процедура КомандаПровести(Команда)
// Перед вызовом сервера, можем выполнить клиентскую валидацию или отобразить сообщение
Если Объект.Сумма < 0 Тогда
ПоказатьПредупреждение(,"Сумма документа не может быть отрицательной.");
Возврат;
КонецЕсли;
// Вызываем серверную процедуру для выполнения основной логики
// Результат работы сервера может быть передан обратно на клиент
Если ПровестиИОбработатьДокументНаСервере() Тогда
ПоказатьОповещениеПользователя("Документ успешно проведен и обработан.", , "Успех");
Иначе
ПоказатьПредупреждение(,"Не удалось провести или обработать документ.");
КонецЕсли;
КонецПроцедура
// В модуле формы на сервере
&НаСервере
Функция ПровестиИОбработатьДокументНаСервере()
// Этот код выполняется на сервере, имеет доступ к данным формы (Объект) и базе данных
Попытка
Если Объект.Сумма > 1000 Тогда
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| Документ.РеализацияТоваровУслуг.Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг КАК ДокументРеализацияТоваровУслуг
|ГДЕ
| ДокументРеализацияТоваровУслуг.СуммаДокумента > &МинимальнаяСумма";
Запрос.УстановитьПараметр("МинимальнаяСумма", 1000);
Выборка = Запрос.Выполнить().Выбрать();
// Сообщения пользователю с сервера передаются на клиент
// или агрегируются и возвращаются функцией
СообщениеДляПользователя = "Найдено документов с большой суммой: ";
Пока Выборка.Следующий() Цикл
СообщениеДляПользователя = СообщениеДляПользователя + Выборка.Ссылка + ", ";
// Здесь может быть какая-то серверная обработка найденных документов
КонецЦикла;
Если Выборка.Количество() > 0 Тогда
Сообщить(СообщениеДляПользователя); // Это сообщение появится у пользователя на клиенте
КонецЕсли;
Объект.Провести(); // Проведение документа на сервере
Иначе
Сообщить("Сумма документа недостаточна для выполнения специальной обработки.");
КонецЕсли;
Возврат Истина; // Успех
Исключение
Сообщить("Ошибка при проведении/обработке: " + ОписаниеОшибки());
Возврат Ложь; // Ошибка
КонецПопытки;
КонецФункции
Глубокое переосмысление архитектуры приложения
Управляемые формы диктуют более строгое разделение между данными и их представлением (похоже на подход Model-View-Controller, хотя 1С не является чистой реализацией MVC). Вся логика работы с данными, включая бизнес-правила, запросы к базе, записи объектов, должна быть вынесена на сервер. На клиенте остаются только функции, ответственные за отображение данных, управление элементами интерфейса, а также минимальная валидация пользовательского ввода (например, проверка формата даты или числа, но не проверка существования элемента в базе данных). Это может потребовать существенного пересмотра существующих алгоритмов и их адаптации под новую модель взаимодействия. Мы будем стремиться к созданию тонких клиентских частей форм, которые лишь "запрашивают" данные и команды у сервера, и толстых серверных частей, которые "знают" как работать с данными и выполнять бизнес-логику.
Оптимизация для тонкого и веб-клиента
Управляемые формы изначально спроектированы для работы в условиях тонкого клиента (специализированное приложение с минимальной нагрузкой на ПК) и веб-клиента (работа через браузер), которые могут функционировать при низкой пропускной способности каналов связи. Это делает оптимизацию критически важной. Мы будем активно применять следующие подходы:
Использование специфичных элементов управляемого интерфейса
При ручной перерисовке форм мы будем использовать элементы, которые разработаны специально для управляемого интерфейса и отличаются от элементов обычных форм. Они предоставляют больше гибкости и возможностей:
ДинамическийСписок: Вместо устаревшего УниверсальноеТабличноеПоле для работы с данными из баз данных, мы будем активно использовать ДинамическийСписок. Это мощный инструмент для отображения списков объектов информационной базы (справочников, документов, регистров). Его преимущества:
ДинамическийСписок запрашивает данные порциями (ленивая загрузка), что значительно снижает нагрузку на сервер и сеть, особенно при работе с большими объемами данных.ДинамическийСписок может автоматически генерировать запрос к базе данных на основе указанной основной таблицы или объекта, что упрощает разработку.ДинамическийСписок, который, в свою очередь, может быть связан с таблицей базы данных.Пример привязки ДинамическийСписок к данным:
// В модуле формы или при создании формы
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Указываем основной источник данных для динамического списка
Элементы.СписокДокументов.УстановитьДинамическийСписок(Новый ДинамическийСписок(ЭтаФорма, Метаданные.Документы.РеализацияТоваровУслуг));
// Можно добавить отборы программно
// Элементы.СписокДокументов.Отбор.Добавить("Контрагент", ВидСравнения.Равно, СсылкаНаКонтрагента);
КонецПроцедуры
Другие элементы: Для создания групп элементов, командных панелей, кнопок и полей ввода используются объекты ГруппаФормы, КоманднаяПанель, ПолеФормы, Кнопка и другие. Все они обладают более широкими возможностями по настройке внешнего вида и поведения, а также тесно интегрированы с системой прав доступа.
Командный интерфейс: Управляемые формы используют командный интерфейс для размещения кнопок и меню. Мы будем формировать команды, привязывать их к обработчикам и размещать на командных панелях формы. Многие стандартные команды для объектов метаданных (создать, скопировать, изменить) генерируются автоматически, что значительно ускоряет разработку.
Адаптация отчетов и обработок
Перевод на управляемые формы не ограничивается только формами документов и справочников. Мы также будем адаптировать существующие отчеты и обработки, так как они должны функционировать в управляемом приложении. Здесь также применяется принцип разделения клиент-серверного кода: вся логика, работающая с данными (формирование запросов, расчеты), выполняется на сервере, а на клиенте остаются только функции для взаимодействия с пользователем (настройка параметров отчета, отображение результатов).
Система компоновки данных (СКД): Для отчетов мы будем активно использовать СКД. Это мощный инструмент для построения отчетов любой сложности, который изначально разработан для управляемого интерфейса. Он позволяет пользователям гибко настраивать отчеты, а разработчикам — легко описывать источники данных, связи, параметры и макеты. Отчеты на СКД максимально эффективно работают в условиях клиент-серверной архитектуры.
Проектирование ролевой модели доступа
Управляемые формы предоставляют более гибкие и гранулированные возможности для настройки прав доступа к элементам интерфейса и данным. Мы будем уделять повышенное внимание проектированию ролей и профилей пользователей. На уровне конфигурации мы можем задавать права на объекты метаданных, а на уровне формы — управлять видимостью, доступностью и возможностью редактирования отдельных элементов (полей, кнопок, групп) в зависимости от текущей роли пользователя. Это позволяет создавать более безопасные и персонализированные интерфейсы, предотвращая несанкционированный доступ к данным или функциям.
Использование Библиотеки стандартных подсистем (БСП)
Если это применимо к нашей конфигурации, мы настоятельно рекомендуем использовать Библиотеку стандартных подсистем (БСП) 1С. БСП — это набор готовых, протестированных и постоянно развивающихся решений для многих типовых задач, характерных для прикладных решений 1С. Использование БСП может значительно упростить разработку и адаптацию функционала в управляемых формах, а также обеспечить единообразие интерфейса и логики. Примеры полезных подсистем БСП:
Интеграция БСП позволяет нам не изобретать колесо для стандартных задач, а сосредоточиться на уникальных аспектах бизнес-логики.
В некоторых случаях, когда необходимо лишь временно обеспечить работу обычных форм в управляемом приложении без их полной переработки, платформа 1С:Предприятие 8 предоставляет свойство конфигурации, позволяющее это сделать.
Свойство конфигурации "Открывать обычные формы в управляемом приложении"
Это свойство находится в свойствах всей конфигурации и может быть установлено в "Использовать" или "Использовать с ограничениями". Активация этого свойства позволяет запускать обычные формы в среде управляемого приложения. Это может быть полезно на промежуточных этапах миграции, когда часть функционала уже переведена, а другая часть пока остается на обычных формах.
Чтобы найти это свойство, нам нужно открыть конфигурацию в режиме "Конфигуратор", перейти в меню "Конфигурация" -> "Свойства", и на вкладке "Основные" найти группу свойств, относящихся к режиму совместимости. Там мы обнаружим "Режим совместимости интерфейса" и сможем выбрать нужный вариант. Если мы выберем "Использовать", обычные формы будут открываться в управляемом приложении, пытаясь максимально имитировать свой внешний вид и поведение.
Назначение и ограничения режима совместимости
Мы должны понимать, что это свойство является скорее временным решением для частичной совместимости и не превращает обычные формы в полноценные управляемые. Они будут работать в режиме совместимости, но при этом:
Этот режим не является заменой полноценной миграции. Мы будем рассматривать его как "костыль" (временное решение) для плавного перехода, но не как конечную цель. В долгосрочной перспективе все обычные формы должны быть переведены в управляемые для полноценного использования всех возможностей современной платформы 1С:Предприятие 8.
В целом, процесс перевода форм из обычной в управляемую — это сложная, но необходимая задача для развития любого прикладного решения на платформе 1С:Предприятие 8. Он требует глубокого понимания архитектуры платформы, принципов работы управляемого приложения и умения проектировать эффективный пользовательский интерфейс с учетом разделения клиент-серверных обязанностей. Мы будем подходить к этой задаче как к комплексному проекту рефакторинга и адаптации, тщательно планируя каждый шаг и тестируя результат, чтобы обеспечить стабильную и производительную работу обновленной конфигурации.