При сопровождении и развитии крупных исторических систем на платформе 1С:Предприятие 8 (например, 1С:Управление производственным предприятием 1.3) разработчики часто сталкиваются с необходимостью перевести часть интерфейса на управляемые формы. Это требуется для подключения мобильных рабочих мест, работы сотрудников на планшетах в торговых залах или на складах, а также для постепенного перехода на современный стек технологий. При этом ломать привычный интерфейс бэк-офиса, работающего в обычном приложении, нельзя.
В этой статье мы подробно разберем, как грамотно организовать совместную работу («гибридный режим») обычных и управляемых форм для одних и тех же документов, избегая архитектурных ошибок и оптимизируя код для дальнейшего сопровождения.
Прежде чем приступать к созданию форм, нам необходимо подготовить саму платформу 1С:Предприятие к работе в гибридном режиме. Для этого откроем конфигуратор, выделим корень конфигурации, откроем его свойства и настроим три важнейших параметра:
Управляемое приложение и обычное приложение. Это позволит нам полноценно проектировать и использовать оба типа интерфейсов в рамках одной информационной базы.Истина. Это ключевой флаг. Без него пользователи толстого клиента в режиме обычного приложения не смогут открыть созданные нами управляемые формы.Истина, если планируется обратная совместимость (открытие старых форм из сеанса управляемого приложения, хотя для мобильных устройств это не применимо).Рассмотрим ситуацию на примере документа. Для реализации нашей задачи у документа должно быть создано как минимум две формы: обычная (для офисных сотрудников на ПК) и управляемая (для работы на планшетах через тонкий или веб-клиент).
Разберем, как правильно сопоставить эти формы в свойствах документа:
Благодаря такой настройке платформа 1С автоматически определяет контекст запуска. Если пользователь авторизовался через толстого клиента (обычное приложение), система откроет обычную форму. Если же авторизация произошла через веб-клиент на планшете или тонкий клиент, платформа автоматически предоставит управляемый интерфейс.
Часто у разработчиков возникает соблазн перенести всю логику во вновь созданный модуль менеджера документа и разделять выполнение кода с помощью директив препроцессора вроде #Если ТонкийКлиент. Разберем по шагам, почему это решение ошибочно.
Модуль менеджера выполняется на сервере. Он предназначен для методов, относящихся к таблице данного класса объектов в целом (например, печать списка, обработка заполнения, кастомизация выбора), а не к конкретному экземпляру (документу). Попытка управлять свойствами элементов формы из модуля менеджера приведет к грубому нарушению клиент-серверной архитектуры.
Правильный архитектурный подход выглядит следующим образом:
1. Разделение логики интерфейса (UI) и бизнес-логики. Вся тяжелая прикладная логика (проведение, расчеты сумм, заполнение связанных табличных частей, проверки) должна быть полностью вынесена из модулей форм. Ее место — в Модуле объекта или в специализированных Общих серверных модулях.
2. Минимизация кода в модулях форм. Модуль обычной формы и модуль управляемой формы должны быть максимально «тонкими». Их задача — перехватить действие пользователя, собрать данные с формы, передать их в серверную функцию для обработки и вывести результат обратно на экран.
3. Использование общих модулей с правильной компиляцией. Для разделения логики вызовов следует создать разные общие модули:
Клиент (обычное приложение)).Клиент (управляемое приложение), Сервер).Для корректного разделения кода, который может вызываться в различных сеансах, мы должны активно применять инструкции препроцессора. Проанализируем пример кода, определяющего логику оповещения пользователя в зависимости от текущего режима запуска:
#Если ОбычноеПриложение Тогда
// Данный блок кода скомпилируется и выполнится только в толстом клиенте обычного приложения
Предупреждение("Документ успешно сохранен в обычном интерфейсе!");
#ИначеЕсли ТонкийКлиент Или ВебКлиент Или МобильныйКлиент Тогда
// Этот блок сработает на планшетах и в управляемом интерфейсе
ПоказатьПредупреждение(, "Документ сохранен в мобильном интерфейсе!");
#КонецЕсли;
Использование директив препроцессора позволяет держать общие алгоритмы в единых модулях, гарантируя, что платформа не попытается выполнить не поддерживаемый в данном контексте метод.
Разрабатывая управляемые формы, которые будут открываться на планшетах (через веб-клиент или мобильный клиент), мы обязательно столкнемся с техническими ограничениями платформы. Выясним основные правила разработки в такой среде:
Вопрос(), Предупреждение() и ОткрытьФормуМодально() мы обязаны использовать их асинхронные аналоги. Разберем пример реализации вопроса пользователю через описание оповещения:
&НаКлиенте
Процедура ПередЗаписью(Отказ, ПараметрыЗаписи)
ОписаниеОповещения = Новый ОписаниеОповещения("ПослеВопросаОЗаписи", ЭтотОбъект);
ПоказатьВопрос(ОписаниеОповещения, "Записать документ?", РежимДиалогаВопрос.ДаНет);
// В управляемом интерфейсе выполнение кода не останавливается на строке ПоказатьВопрос.
// Дальнейшая логика переносится в процедуру-обработчик.
Отказ = Истина;
КонецПроцедуры
&НаКлиенте
Процедура ПослеВопросаОЗаписи(Результат, ДополнительныеПараметры) Экспорт
Если Результат = КодВозвратаДиалога.Да Тогда
// Записываем объект без вызова стандартного диалога
ЭтотОбъект.Записать();
КонецЕсли;
КонецПроцедуры
ПоместитьФайл() следует использовать НачатьПомещениеФайлаНаСервер().Новый COMОбъект("Excel.Application") вызовет критическую ошибку. Любой импорт или экспорт файлов должен осуществляться на стороне сервера с использованием стандартных средств платформы (чтение XML, JSON или табличных документов).Перевод отдельных документов на управляемые формы с сохранением работоспособности в обычном приложении — это абсолютно стандартная и поддерживаемая платформой 1С задача. Главное — строго соблюдать разделение контекстов разработки, избегать модальных вызовов в управляемом коде и не перегружать модули форм бизнес-логикой, доверяя обработку данных серверным механизмам.