В процессе разработки на платформе 1С:Предприятие часто возникает соблазн объединить гибкость программного создания элементов формы с удобством визуального редактора. Представим ситуацию: мы программно «дорисовали» форму в режиме Предприятие, добавили десятки реквизитов и элементов, а теперь хотим увидеть этот результат в Конфигураторе, чтобы вручную подправить положение кнопок или сгруппировать элементы. Рассмотрим, насколько это реализуемо, какие существуют технические ограничения и какие инструменты платформы могут нам помочь в автоматизации этого процесса.
Для начала проанализируем, почему задача «выгрузить форму из Предприятия в Конфигуратор» не имеет простого решения «одной кнопкой». Разберем внутреннее устройство платформы. В 1С существует жесткое разделение между описанием метаданных и экземпляром объекта.
Когда мы работаем в Конфигураторе, форма хранится в виде декларативного описания (в современных версиях это XML-структура). Это статичный чертеж. Когда пользователь запускает Предприятие и открывает форму, платформа считывает этот «чертеж» и создает в оперативной памяти живой объект УправляемаяФорма. Если мы используем программный код для изменения этой формы, например, вызываем метод Элементы.Добавить(), мы меняем объект в памяти, но не исходный «чертеж» в базе данных.
Платформа 1С не имеет встроенного механизма обратной сериализации (преобразования) текущего состояния элементов формы из памяти обратно в XML-описание метаданных, пригодное для Конфигуратора. Это связано с тем, что программно созданные элементы могут иметь сложные зависимости и динамические обработчики событий, которые невозможно однозначно интерпретировать в статичном визуальном редакторе.
Несмотря на отсутствие прямой кнопки выгрузки из «живой» формы, платформа предоставляет мощные средства для работы с файлами метаданных. Если наша цель — быстро переносить изменения между конфигурациями без ручного сравнения и объединения всей базы, мы можем воспользоваться параметрами командной строки. Проанализируем возможности ключей /DumpConfigToFiles и /LoadConfigFromFiles.
Многие разработчики ошибочно полагают, что эти функции работают только со всей конфигурацией целиком. Однако это не так. Рассмотрим пример использования файла списка для выборочной работы с объектами:
// Пример команды для выгрузки конкретной формы (через файл списка)
1cv8.exe DESIGNER /F "C:\Base1C" /DumpConfigToFiles "C:\Dump" -listFile "C:\list.txt"
// Содержимое файла list.txt:
Справочник.Номенклатура.Форма.ФормаЭлемента
Разберем параметры подробнее:
-files для указания конкретных файлов XML, которые должны попасть в конфигурацию.Этот механизм позволяет нам работать с формой как с XML-файлом. Если мы напишем скрипт, который умеет конвертировать программно созданные элементы в формат XML-описания формы 1С, мы сможем «впихнуть» их в конфигурацию через этот механизм. Однако сложность структуры XML-форм 1С делает этот путь крайне трудозатратным.
Рассмотрим более практичный подход, который часто используют опытные разработчики. Вместо того чтобы пытаться обмануть Конфигуратор и засунуть в него XML, мы можем заставить Предприятие написать за нас программный код. Если мы уже модифицировали форму кодом и результат нас устраивает, мы можем запустить процедуру-инспектор, которая обойдет коллекцию ЭтаФорма.Элементы и создаст текст модуля.
Посмотрим на пример логики такой обработки:
Процедура ГенерироватьКодСозданияЭлементов(Форма)
Для Каждого Элемент Из Форма.Элементы Цикл
Если Элемент.Имя = "ГруппаКнопок" Тогда // Пример фильтрации
ТекстКода = "НовыйЭлемент = Элементы.Добавить(""" + Элемент.Имя + """, Тип(""" + ТипЗнч(Элемент) + """), " + Элемент.Родитель.Имя + ");";
// Далее перечисляем установку свойств
ТекстКода = ТекстКода + Символы.ПС + "НовыйЭлемент.Заголовок = """ + Элемент.Заголовок + """;";
Сообщить(ТекстКода);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Такой подход позволяет реализовать следующий цикл разработки:
ПриСозданииНаСервере в Конфигураторе.Это не делает форму «визуальной» в редакторе, но позволяет сохранить поддержку типовой конфигурации, так как изменения живут в коде, а не в измененном объекте метаданных. При обновлении типовой формы нам не придется вручную восстанавливать визуальные элементы — код сделает это за нас.
Выясним причину, по которой многие разработчики отказываются от программной модификации в пользу расширений. Механизм расширений конфигурации был создан именно для решения проблемы «обновления на поддержке». Вместо того чтобы кодить элементы или пытаться выгружать/загружать формы, мы можем создать расширение и визуально добавить элементы в нем.
Преимущества этого метода:
Проанализируем ситуацию с современными инструментами разработки. 1C:Enterprise Development Tools (EDT) базируется на Eclipse и хранит все объекты в текстовом (XML/YAML) виде по умолчанию. В отличие от старого Конфигуратора, где формы упакованы в бинарные файлы .cf, в EDT форма всегда представлена набором файлов.
Для разработчика это открывает возможность использовать внешние редакторы или скрипты на Python/JS для модификации структуры формы. Если ваш компьютер («ишак», как выразился автор темы) потянет EDT, то вопрос «выгрузки формы в XML» отпадет сам собой — она и так там находится в реальном времени. Это позволяет использовать системы контроля версий (Git) и видеть каждое изменение в структуре формы как текстовый диф (diff).
Подводя итоги нашего анализа, можно сделать следующие выводы. Прямого способа «выгрузить программно отрисованную форму в визуальный редактор» не существует из-за архитектурных особенностей платформы. Однако, в зависимости от ваших задач, мы рекомендуем использовать одну из следующих стратегий:
/DumpConfigToFiles с ключом -listFile для точечной работы с объектами, минуя ручное объединение конфигураций.Помните, что избыточная программная модификация форм усложняет отладку и поддержку. Старайтесь использовать возможности платформы по максимуму, прибегая к «кодингу интерфейса» только там, где динамика формы действительно необходима бизнес-процессу.