При изучении современных типовых конфигураций, таких как Зарплата и Управление Персоналом 3.1 или ERP Управление предприятием, разработчики часто сталкиваются с тем, что визуальный редактор формы в Конфигураторе оказывается практически пустым, в то время как при запуске приложения пользователь видит сложный, насыщенный элементами интерфейс. Рассмотрим подробнее, почему компания «1С» и опытные разработчики перешли от визуального проектирования к программному созданию форм, и какие реальные преимущества это дает при сопровождении систем.
Разберем типичную ситуацию: вы добавили на типовую форму документа несколько полей и кнопок через визуальный редактор. При выходе очередного обновления от поставщика выясняется, что структура этой формы существенно изменилась. При попытке объединения конфигураций стандартные механизмы сравнения/объединения могут некорректно сопоставить визуальные элементы, что приведет к «каше» на форме или потере ваших доработок.
Проанализируем, как программный подход решает эту проблему. Если ваши доработки вынесены в отдельную процедуру, которая вызывается в теле стандартного события ПриСозданииНаСервере, то при обновлении вам достаточно перенести всего одну строку вызова этой процедуры. Весь остальной код создания элементов управления остается нетронутым в отдельном модуле или в конце модуля формы. Это минимизирует вероятность ошибок и многократно ускоряет процесс «накатывания» обновлений на кастомизированные базы.
Выясним причину массового использования этого метода в продуктах 1С. Современные конфигурации строятся по модульному принципу. Например, механизм работы с подписантами документов или работа с контактной информацией — это универсальные подсистемы БСП. Чтобы разработчику не приходилось вручную рисовать одни и те же группы полей в сотнях различных документов, создается универсальный программный код.
Рассмотрим, как это работает на практике. При открытии формы система анализирует настройки объекта и динамически «дорисовывает» нужные поля. Если в настройках организации добавилось новое ответственное лицо, оно автоматически появится во всех формах документов без их ручной правки в Конфигураторе. Это позволяет создавать гибкие, адаптивные интерфейсы, которые подстраиваются под бизнес-логику на лету.
Программное создание интерфейса в управляемом приложении 1С 8.3 — это двухэтапный процесс. Разберем по шагам, какие методы платформы при этом используются.
Шаг 1. Создание реквизитов формы. Реквизиты — это «фундамент» данных, к которым будут привязаны визуальные элементы. Для их создания используется метод ИзменитьРеквизиты(). Посмотрим на пример кода:
// Описываем новый реквизит
ДобавляемыеРеквизиты = Новый Массив;
ДобавляемыеРеквизиты.Добавить(Новый РеквизитФормы("ДополнительноеПоле", Новый ОписаниеТипов("Строка"), , "Заголовок поля", Истина));
// Применяем изменения на форме
ЭтаФорма.ИзменитьРеквизиты(ДобавляемыеРеквизиты);
Шаг 2. Создание элементов управления. После того как данные (реквизиты) подготовлены, мы должны отрисовать само поле ввода или кнопку. Для этого используется коллекция Элементы и метод Добавить(). Проанализируем пример добавления поля ввода:
// Добавляем элемент "Поле ввода"
НовыйЭлемент = Элементы.Добавить("ДекорацияЗаголовок", Тип("ПолеФормы"), Элементы.ГруппаШапка);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
НовыйЭлемент.ПутьКДанным = "ДополнительноеПоле"; // Привязка к созданному ранее реквизиту
Важно помнить, что метод ИзменитьРеквизиты() является ресурсоемким, так как вызывает переинициализацию формы. Опытные разработчики рекомендуют собирать все необходимые изменения в один массив и вызывать этот метод один раз за весь цикл создания формы.
С развитием инструментов разработки, таких как 1C:Enterprise Development Tools (EDT), программный код стал предпочтительнее визуальных объектов. Дело в том, что визуальная форма в 1С хранится внутри конфигурации как сложный XML-структурированный файл. При работе нескольких программистов над одной формой через системы контроля версий (например, Git) слияние (merge) таких XML-файлов часто превращается в кошмар из-за конфликтов структур.
В то же время программный код — это обычный текст. Его легко сравнивать, легко отслеживать изменения (кто, когда и зачем добавил конкретный элемент) и намного проще объединять результаты работы разных участников команды. Это делает разработку более прозрачной и предсказуемой.
Использование расширений конфигурации стало стандартом де-факто для доработки типовых решений. Программное создание элементов в расширениях считается более «безопасным». Если вы визуально измените типовую форму в расширении, а поставщик в новом релизе радикально ее перестроит, расширение может «слететь» или вызвать критическую ошибку при запуске. Если же вы программно ищете на форме нужную группу (например, по имени или через «якорь») и вставляете туда свои элементы, вероятность конфликта значительно снижается.
Рассмотрим концепцию «Якорей». Это пустые группы или элементы, созданные в Конфигураторе специально для того, чтобы программный код мог зацепиться за них и вставить рядом динамические элементы. Это отличный компромисс между визуальным и программным подходом.
Подводя итог нашему анализу, можно выделить следующие ключевые выводы:
Таким образом, использование методов Элементы.Добавить() и ИзменитьРеквизиты() является признаком профессионального подхода к разработке на платформе 1С:Предприятие 8.3, обеспечивая чистоту кода и легкость дальнейшего сопровождения системы.