Как реализовать редактирование контактной информации стороннего объекта в форме другого объекта в БСП

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

Штатная архитектура сквозного редактирования контактной информации

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

Рассмотрим порядок реализации:

1. Создание реквизита формы: На форме создается дополнительный реквизит (например, ФизическоеЛицоОбъект) с типом СправочникОбъект.ФизическиеЛица. Именно поэтому при обращении на клиенте доступны свойства объекта, включая ФизическоеЛицоОбъект.Ссылка.
2. Чтение объекта на сервере: При инициализации формы или при изменении ссылки на связанный элемент на сервере выполняется получение объекта через метод ПолучитьОбъект() и его помещение в созданный реквизит формы.
3. Подключение обработчиков БСП: Процедуры подсистемы УправлениеКонтактнойИнформацией вызываются повторно для второго объекта. В них передается путь к реквизиту связанного объекта и имя группы формы, куда следует динамически внедрить элементы управления КИ.
4. Сохранение изменений: В серверном событии ПередЗаписьюНаСервере или ПослеЗаписиНаСервере вызывается запись связанного объекта, если реквизит формы был модифицирован.

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

Выясним причину частой ошибки при блокировке данных. Платформенный метод ЗаблокироватьДанныеДляРедактирования имеет контекст выполнения: Сервер, толстый клиент, внешнее соединение. На тонком клиенте вызвать этот метод напрямую нельзя.

Посмотрим на пример вызова серверной процедуры для установки блокировки:

&НаСервере
Процедура ЗаблокироватьСвязанныйОбъектНаСервере()
    Если Не ФизическоеЛицоОбъект.Ссылка.Пустая() Тогда
        ЗаблокироватьДанныеДляРедактирования(
            ФизическоеЛицоОбъект.Ссылка, 
            ФизическоеЛицоОбъект.ВерсияДанных, 
            УникальныйИдентификатор
        );
    КонецЕсли;
КонецПроцедуры

Параметр ВерсияДанных обеспечивает механизм оптимистической блокировки. Если связанный объект уже был изменен и записан в другой сессии параллельно, система сгенерирует исключение, защищая данные от неконтролируемого перезаписывания.

Вывод контактной информации для нескольких объектов одного типа

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

Рассмотрим способы обхода этой проблемы:

1. Разделение по группам: Элементы контактной информации каждого объекта должны размещаться в строго изолированных родительских группах (например, ГруппаКИ_ПервоеЛицо и ГруппаКИ_ВтороеЛицо).
2. Передача префиксов и путей к данным: При вызове процедур инициализации подсистемы необходимо явно указывать различные пути к реквизитам формы для каждого объекта.
3. Вывод в режиме только для чтения: Если для второго объекта не требуется интерактивное редактирование полей ввода КИ, оптимально отказаться от создания тяжелого реквизита объекта и воспользоваться серверными функциями УправлениеКонтактнойИнформацией.КонтактнаяИнформацияОбъекта(), выведя строковые представления в обычные надписи или поля только для чтения.

Почему контактная информация хранится в табличных частях, а не в регистрах сведений

В современных версиях БСП контактная информация перенесена из периодических регистров сведений непосредственно в табличные части объектов-владельцев. Проанализируем архитектурные причины этого решения:

1. Атомарность транзакций: Изменение контактной информации происходит строго в одной транзакции с самим объектом, что полностью исключает рассинхронизацию данных.
2. Упрощение прав доступа (RLS): Доступ к КИ автоматически ограничивается правами на сам объект-владелец, что избавляет от необходимости настройки сложных правил для отдельного регистра.
3. Единое версионирование: Вся история изменения контактов автоматически сохраняется стандартной подсистемой версионирования объектов вместе с изменением реквизитов справочника.
4. Производительность: Считывание контактной информации объекта при его открытии происходит без дополнительных левых соединений с таблицами регистров.