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

← На главную

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

Интерактивное добавление элементов через Дизайнер

Рассмотрим ситуацию, когда мы просто открываем форму в расширении и перетаскиваем на нее новую кнопку или поле ввода. Платформа 1С позволяет делать это довольно легко. Основным преимуществом здесь является скорость: мы сразу видим результат, можем настроить заголовки, ширину и привязки к данным без написания лишних строк кода.

Однако при таком подходе возникают скрытые риски, которые проявляются при обновлении основной конфигурации:

Проблема «осиротевших» элементов. Разберем сценарий: вы добавили поле ввода внутрь группы «ГруппаИнформация». Если в следующем обновлении типовой конфигурации вендор (например, фирма «1С») удалит эту группу или переименует ее, ваше расширение может повести себя непредсказуемо. Элемент либо станет невидимым, либо переместится в корень формы, нарушая всю верстку.
Жесткое заимствование формы. Чтобы добавить элемент интерактивно, вам необходимо «заимствовать» саму форму в расширение. Это создает жесткую связь с конкретной версией формы. При масштабных изменениях в основной конфигурации (например, переходе на другую версию БСП) такая форма в расширении может стать причиной критической ошибки при запуске.
Конфликты при командной разработке. Если вы используете EDT и системы контроля версий (Git), то заметите, что интерактивные изменения записываются в сложные XML-структуры. Анализировать разницу (diff) между версиями в таких файлах крайне сложно, что ведет к трудноразрешимым конфликтам при слиянии веток.

Программное создание элементов: надежность и гибкость

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

Выясним, почему опытные разработчики часто выбирают именно этот путь:

1. Устойчивость к обновлениям. Программный код более гибко реагирует на изменения структуры. Мы можем сначала проверить наличие родительской группы, прежде чем добавлять в нее элемент. Посмотрим на пример реализации:


&После("ПриСозданииНаСервере")
Процедура Ист_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    
    // Проверяем, существует ли группа, в которую хотим добавить поле
    Родитель = Элементы.Найти("ГруппаШапкаЛевая");
    Если Родитель = Неопределено Тогда
        Родитель = Элементы.ГруппаШапка; // Резервный вариант
    КонецЕсли;
    
    // Добавляем новый элемент программно
    НовыйЭлемент = Элементы.Добавить("Ист_ДополнительныйРеквизит", Тип("ПолеФормы"), Родитель);
    НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
    НовыйЭлемент.ПутьКДанным = "Объект.Ист_ДополнительныйРеквизит";
    
КонецПроцедуры

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

3. Производительность. Платформа тратит меньше ресурсов на хранение «разницы» (diff) формы, если эта разница минимальна. Интерактивные изменения заставляют систему при каждом открытии формы «склеивать» XML основной формы и расширения. Выполнение чистого программного кода зачастую происходит быстрее, чем сложный парсинг метаданных.

Методика «Золотой середины»

Разберем наиболее сбалансированный подход, который рекомендуют эксперты для крупных проектов. Он сочетает в себе сильные стороны обоих методов:

Данные — в Дизайнере. Реквизиты формы или реквизиты объекта, которые должны хранить значения, лучше добавлять через визуальный интерфейс расширения. Это гарантирует правильную типизацию и связь с базой данных.
Интерфейс — в Коде. Сами визуальные элементы (кнопки, поля, декорации) создаются программно в процедуре ПриСозданииНаСервере.

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

Особенности работы в различных средах

Проанализируем влияние среды разработки. При использовании классического Конфигуратора интерактивный метод кажется удобным и стабильным. Однако, если ваша команда переходит на EDT (Enterprise Development Tools), программный метод становится практически обязательным. В EDT работа с кодом реализована намного эффективнее, а визуальный редактор расширений может иногда работать медленнее или приводить к избыточному заимствованию объектов.

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

Заключение

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

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