При разработке конфигураций на платформе 1С программисты часто сталкиваются с дилеммой: где именно настраивать свойства данных? Платформа позволяет задать такие параметры, как ПараметрыВыбора, СвязиПараметровВыбора или Формат, как непосредственно в объекте метаданных (справочнике, документе), так и в конкретном элементе формы. На первый взгляд эти настройки дублируют друг друга, но на практике они работают по строгим правилам приоритетности и взаимодействия. Разберем детально эти механизмы, чтобы понимать, какой подход выбрать в конкретной ситуации.
Рассмотрим базовый принцип работы платформы 1С: настройки элемента формы всегда имеют более высокий приоритет, чем аналогичные настройки в метаданных реквизита объекта. Проанализируем, как это происходит на практике:
ПараметрыВыбора, они будут применены немедленно.Выясним причину такого поведения: это позволяет разработчику задать «поведение по умолчанию» в метаданных, которое будет работать во всей системе, но при необходимости переопределить его для конкретной специализированной формы, не затрагивая остальную конфигурацию.
Важно подчеркнуть, что не все свойства подчиняются правилу безусловного приоритета формы. Исключением является свойство ПроверкаЗаполнения. Разберем по шагам, как отрабатывает этот механизм:
В отличие от визуальных настроек, проверка заполнения выполняется в двух контекстах. Если вы установили проверку и в объекте, и на форме, система выполнит обе. При записи объекта (на сервере) будет вызвана стандартная проверка метаданных, а при работе с формой — проверка интерфейсного уровня. Это единственное свойство, где настройки «суммируются», а не замещаются, что гарантирует целостность данных даже при программной записи объекта без участия формы.
Проанализируем важный нюанс, связанный с типами данных. Посмотрим на ситуацию, когда нам нужно ограничить выбор пользователя. Настройки формы позволяют только сужать область выбора, определенную в метаданных, но никогда не позволяют ее расширить.
Например, если в метаданных реквизита Склад указан тип СправочникСсылка.Склады, то через настройки элемента формы мы можем:
Однако мы не сможем через настройки формы разрешить в этом поле выбор из справочника Контрагенты. Типизация, заданная в объекте, является абсолютным пределом для интерфейсных настроек.
Рассмотрим подробнее работу со свойством СвязиПараметровВыбора (ChoiceParameterLinks). Здесь действует правило «полного замещения». Если вы решите настроить хотя бы одну связь параметров на уровне формы, платформа полностью проигнорирует все связи, настроенные для этого реквизита в метаданных.
Рассмотрим пример:
В метаданных реквизита Договор настроена связь по владельцу (поле Контрагент). Если на форме в элементе Договор вы добавите новую связь (например, фильтр по организации), то связь по контрагенту, заданная в метаданных, перестанет работать, если вы не продублируете ее явно в настройках элемента формы. Таким образом, настройки связей не дополняют друг друга, а работают по принципу «всё или ничего».
Свойства Формат, Маска и Подсказка также следуют правилу приоритета формы. Однако здесь есть тонкость в использовании Формата редактирования. Рассмотрим ситуацию:
Если в метаданных задан Формат редактирования (например, для даты), он будет автоматически подтягиваться во все формы. Но как только вы измените параметры отображения на самой форме, системная связь с метаданными разрывается. Это удобно использовать для унификации интерфейса: задав формат один раз в метаданных, вы обеспечиваете единообразие во всей конфигурации.
Проанализируем ситуацию, когда метаданные управляют «жизненным циклом» элемента формы. Если реквизит объекта привязан к Функциональной опции, и эта опция в текущий момент выключена, элемент формы может стать невидимым или недоступным автоматически. В данном случае настройки метаданных (связь с ФО) оказываются «сильнее» настроек формы (свойство Видимость), так как они определяют бизнес-логику приложения в целом.
Выясним, когда настройки формы становятся единственно возможным вариантом. Это касается динамического изменения фильтров в процессе работы пользователя. Свойства метаданных статичны — вы не можете изменить их программно «на лету» в сеансе пользователя.
Если вам нужно изменить параметры выбора в зависимости от сложного условия, которое вычисляется прямо сейчас в форме, вы должны использовать программное обращение к элементу формы:
// Пример динамической установки параметров выбора в форме
НовыйПараметр = Новый ПараметрВыбора("Отбор.Статус", Перечисления.СтатусыЗаказов.Согласован);
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(НовыйПараметр);
Элементы.ЗаказПокупателя.ПараметрыВыбора = Новый ФиксированныйМассив(МассивПараметров);
Такой подход применим только к Элементам формы, но не к Реквизитам объекта напрямую.
При разработке в расширениях конфигурации рекомендуется отдавать предпочтение настройкам на уровне формы. Рассмотрим почему: изменение метаданных основного объекта в расширении (например, изменение параметров выбора в справочнике) может привести к конфликтам при обновлении основной конфигурации поставщиком. Изменение же свойств элемента формы в расширении затрагивает только интерфейсный слой и считается более «безопасным» методом кастомизации.
Подводя итог, сформулируем правила выбора места для настроек:
Понимание этих нюансов позволяет создавать более гибкие и надежные решения на платформе 1С, эффективно используя иерархию настроек и избегая логических ошибок при проектировании интерфейсов.