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

09 марта 2013

Предисловие

При разработке или модификации прикладных решений на платформе 1С:Предприятие 8.x очень часто необходимо выполнять какое-либо стандартное действие для группы объектов конфигурации (например, справочников). Для того, чтобы не описывать в модуле каждого объекта проделываемые действия, разработчик может воспользоваться стандартным механизмом платформы - подпиской на событие. 

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

Стандартное поведение

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

Подписки на события объекта "Справочник"

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

Схема вызова обработчиков на события для справочников

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


При записи элемента справочника, будь то новый элемент или существующий, вызываются три обработчика: "ОбработкаПроверкиЗаполнения" (на этом этапе обработчик может проверить корректность введенных данных и в случае, если есть ошибки, отказаться от записи), "ПередЗаписью" (пока объект не записан в базу можно корректировать значения реквизитов и проверить какие-либо дополнительные условия) и затем "ПриЗаписи" (запись в базу произведена, но транзакция не закрыта, разработчик может проверить данные после записи и при необходимости отменить транзакцию).

Событие "ПередУдалением" возникает только в случае непосредственного удаления объекта из информационной базы. Обычно, ни один пользователь не обладает правами на непосредственное удаление без проверки ссылочной целостности. Удаление всегда должно производиться обработкой "Удаление помеченных объектов". В последнем случае обработчик "ПередУдалением" тажке вызывается.

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

Вызываемые обработчики на события

Касательно других объектов конфигурации работа механизма подписок на события будет аналогичной, могут лишь различаться события и их порядок. Подробнее смотрите в синтаксис-помощнике.

Недокументированная сторона

Теперь рассмотрим интересную ситуацию. Допустим, для нашего справочника "ПростойСправочник" определены три подписки на событие "ПередЗаписью":

Созданные подписки на события для тестового справочника

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

Порядок вызова подписок на события для  одного события объекта метаданных

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

Отступление

Вы спросите: "Для чего создавать несколько подписок для одного события объекта конфигурации?". Ответ прост. Если разработкой занимаются несколько человек, то вмешательство в созданные механизмы друг друга может привести к некорректной работе программы. В таких случаях самым логичным будет создавать отдельные подписки на события каждому разработчику в соответствии с поставленной задачей. Конечно, не исключено, что в дальнейшем они будут объединены в единую процедуру-обработчик.


comments powered by Disqus