Содержание:

1. В чем разница между обычными и управляемыми формами
2. Автоматическое обновление организации управляемых форм — как это работает
3. Что делать, если автоматики недостаточно? Ручная доработка
4. А что с отбором обычных форм

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

Платформа 1С предоставляет мощный инструментарий для автоматизации этого процесса, особенно когда речь идет об управляемых формах. Давайте разберемся, как работает этот механизм и какие best practices следует применять разработчикам.

В чем разница между обычными и управляемыми формами

Обычные формы (до платформы 8.2): Формы создавались и хранились в самом файле конфигурации (как данные). При обновлении конфигурации форма полностью заменялась на новую версию из поставщика. Любые изменения, внесенные в форму в базе данных, безвозвратно терялись. Это требовало от разработчиков крайней осторожности и часто ручного переноса правок.

Управляемые формы (платформа 8.3 и новее): Форма описывается в конфигурации, но в базе данных хранится не сама форма, а её макет и настройки (пользовательские представления, отборы, сортировки, состав колонок и т.д.). Это архитектурное решение кардинально меняет подход к обновлению.

Автоматическое обновление организации управляемых форм — как это работает

Платформа 1С: Предприятие 8.3+ обладает встроенным «интеллектом» для автоматического применения обновлений к управляемым формам. Процесс происходит следующим образом:

1.  Сравнение структур: При обновлении конфигурации платформа сравнивает две версии формы:

    – Старая версия: Та, что была в предыдущей версии конфигурации.

    – Новая версия: Та, что пришла с обновлением от поставщика.

2.  Анализ изменений: Механизм определяет, какие изменения были внесены в новую версию:

    – Добавление нового реквизита или элемента управления (поля, кнопки, группы).

    – Удаление существующего реквизита или элемента.

    – Перемещение элемента внутри формы (изменение иерархии, родителя).

    – Изменение свойств элемента (заголовок, ширина, видимость и пр.).

3.  Слияние (Merge) изменений: Ключевой этап. Платформа пытается наложить изменения новой конфигурации на существующие пользовательские настройки формы. Например:

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

    –  Если пользователь изменил ширину колонки в списке, а разработчик в новой версии изменил заголовок этой колонки, то будет применено оба изменения: и новый заголовок (из конфигурации), и пользовательская ширина (из данных).

    – Если элемент был удален из конфигурации, он будет удален и со всех пользовательских форм.

4.  Сохранение пользовательских настроек: Все индивидуальные настройки расположения, состав колонок, отборы и сортировки, сделанные пользователями, максимально сохраняются.

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

Что делать, если автоматики недостаточно? Ручная доработка

Несмотря на эффективность автоматического обновления, бывают сложные случаи, требующие вмешательства разработчика.

1. Конфликтующие изменения:

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

2. Сложные логические правки:

Если изменения в форме не структурные, а логические (изменение алгоритма работы, добавление сложной обработки событий), это всегда требует отдельного внимания и переноса методами встроенного языка.

3. Best Practices для разработчиков:

– Не удаляйте реквизиты, а делайте их невидимыми. Если сразу удалить реквизит, связанный с элементом формы, этот элемент пропадет у всех пользователей. Лучше сначала в версии N сделать элемент управления невидимым (`Видимость = Ложь`), а в версии N+1 — удалить его. Это даст пользователям время привыкнуть к изменениям.

– Используйте комментарии в коде. При внесении изменений, критичных для обновления, добавляйте комментарии для коллег, например: `// Внимание! Изменена структура группы “Основное”. При обновлении возможна потеря пользовательских layout-настроек этой группы`.

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

– Для сложных переносов используйте обработчики события «ПриОбновленииКопированияНастройкиФормы». Это мощный механизм, позволяющий программно вмешаться в процесс копирования настроек формы при обновлении конфигурации и разрешить конфликты по собственным алгоритмам.

А что с отбором обычных форм

Для обычных форм автоматического механизма обновления, сопоставимого с управляемыми, не существует. Форма считается монолитом. Стандартная стратегия такова:

1.  При обновлении конфигурации форма полностью заменяется на новую версию из поставщика.

2.  Все изменения, внесенные в форму в базе данных, теряются.

Как быть? Есть только два цивилизованных пути:

– Перенос правок в конфигурацию. Все необходимые изменения формы должны быть внесены в саму конфигурацию (в файл `.cf` или `.cfe`). Затем эта обновленная конфигурация поставляется пользователям.

– Отказ от правок в базе. Для обычных форм крайне не рекомендуется делать изменения непосредственно в базе данных, так как они не сохранятся при следующем обновлении.

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

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

Специалист компании ООО “Кодерлайн”,

Щербина Наталья