Изменить в расширении и контролировать 1с

Обновлено: 07.07.2024

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.14.1565.

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

Добавление собственных параметров сеанса и значений перечислений

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

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

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

Например, вы заимствовали перечисление и добавили в него собственное значение Отменен.

Если в момент применения расширения проблем не возникло, то будет выполнена реструктуризация базы данных и все собственные значения перечислений будут записаны в неё. В результате вы можете использовать значение Отменен в форме заказа, чтобы указать состояние заказа.

Если после этого вы деактивируете расширение, то собственные значения останутся в базе данных, но не будут показаны в пользовательском режиме. Вместо этого будет выведена надпись <Объект из отключенного расширения конфигурации>.

Также эти значения не будут доступны вам из встроенного языка:

При последующем подключении расширения собственные значения расширения будут восстановлены.

Комментарии к объектам в расширении

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

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

Ослабление контроля обработчиков событий при применении расширения

Раньше при расширении модулей количество параметров обработчика события в расширении и в расширяемом модуле должно было быть одинаковым. Платформа контролировала это соответствие и не применяла расширение метода, если количество параметров отличалось.

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

Раньше это приводило к тому, что расширение не применялось, так как количество параметров не совпадало. Теперь мы отменили этот контроль, и при применении расширения количество параметров и описателей Знач в обработчиках событий не контролируется.

Упрощение работы с расширениями формы

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

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

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

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

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

Если вы захотите изменять реквизиты, параметры и команды, их нужно в явном виде заимствовать в расширение. Для этого в редакторе формы есть контекстная команда, а заимствованные элементы отображаются чёрным цветом.

Работа с формами, заимствованными ранее, никак не изменяется. Они работают так, как будто все возможные реквизиты, команды и параметры были заимствованы вручную.

Мы надеемся, что эти изменения сделают ваши расширения более стабильными, уменьшат их зависимость от расширяемой конфигурации и упростят адаптацию расширений в тех случаях, когда возникает их «нестыковка» с новой версией расширяемой конфигурации.

Начиная с версии платформы 8.3.15 в расширениях можно использовать аннотацию &ИзменениеИКонтроль. При этом важна именно версия платформы, а не режим совместимости. То есть, если у Вас платформа 8.3.15, а режим совместимости установлен 8.3.12, то аннотация &ИзменениеИКонтроль будет работать.

Для примера использования создадим простую обработку с одной командой на форме и со следующим программным кодом в модуле:

Расширение не применилось, так как отличается текст процедуры в исходной конфигурации и в расширении.

Это позволит избежать ошибок, когда после обновления конфигурации был изменен модуль, для которого в расширении была использована аннотация &Вместо.

Автоматическое обновление модуля в расширении можно выполнить только если настроено сравнение/объединение с помощью внешних программ.

В любом случае использование аннотации &ИзменениеИКонтроль позволит избежать ручного сравнения всех процедур и функций, где была использована аннотация &Вместо. Теперь сравнивать нужно будет только те процедуры и функции, где код в исходной конфигурации был изменен в результате обновления.

Но если бы наша процедура была клиентской, то расширение бы все равно применилось, несмотря на то что отличается текст процедуры.

Реализовано в версии 8.3.15.1489.

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

Упрощение поддержки небольших изменений в методах

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

Но часто возникают ситуации, когда вы не хотите полностью менять поведение метода конфигурации, а хотите лишь немного подкорректировать его. Так, чтобы основное «содержание» метода менялось бы вместе с изменениями конфигурации, и в то же время в нём сохранялись ваши небольшие изменения.

Специально для таких небольших доработок мы сделали компромиссное решение – новую аннотацию &ИзменениеИКонтроль. Она позволяет вам добавить собственные изменения в метод, сохраняя, при этом, его исходный текст.

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

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

В такой ситуации вы можете заимствовать этот метод в расширение, и использовать при этом аннотацию &ИзменениеИКонтроль.

Таким образом, заимствованный модуль будет содержать сразу два «варианта» текста:

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

Несмотря на всё удобство аннотации &ИзменениеИКонтроль, мы всё равно рекомендуем подходить к её использованию очень взвешенно. Основным сценарием для расширения типовых конфигураций являются аннотации &Перед и &После. Аннотацию &ИзменениеИКонтроль вы можете использовать тогда, когда &Перед и &После не позволяют достичь желаемого результата.

Облегчение поддержки расширений в случае переименования объектов конфигурации

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

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

Это понятное ограничение, но технически следовать ему не очень удобно. Такое переименование в расширении приходится выполнять вручную. К тому же не всегда бывает ясно, какое исходное имя было у переименованного объекта.

Чтобы облегчить вам эту работу, мы сделали следующие доработки:

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

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

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

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

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

Облегчение подключения «универсальных» расширений

«Универсальными» мы, условно, называем такие расширения, которые приносят в конфигурацию свою функциональность, и, как правило, не содержат заимствованных объектов. Например, это может быть расширение, добавляющее в конфигурацию какие-то обработки или отчёты.

Пользователи конфигурации, у которых есть роли, автоматически дающие права на новые объекты, смогут воспользоваться этими обработками и отчётами. Но дать права на них другим пользователям бывает сложно.

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

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

Чтобы упросить создание и подключение «универсальных» расширений, мы внесли в механизм некоторые доработки, которые позволяют работать по следующему сценарию:

На предприятии некоторым ответственным пользователям дается дополнительное право администрирования расширений конфигурации. Благодаря этому они могут самостоятельно (без участия администратора) подключать новые расширения.
Эти пользователи, например, скачивают из Интернета расширение, подключающее новую печатную форму.
С помощью стандартной функции Управление расширениями конфигурации они добавляют это расширение в информационную базу.

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

Во-первых, теперь при создании расширения в нем автоматически создаётся роль, имя которой формируется по шаблону <ПрефиксРасширенияКонфигурации>_ОсновнаяРоль. Эта роль устанавливает права для новых собственных объектов.

Эта роль сразу же добавляется в свойство Основные роли расширения (возможность модифицировать основные роли мы добавили в версии 8.3.14).

Таким образом, мы избавляем вас от необходимости «механически» создавать роли, дающие полный доступ к объектам расширения. Кроме этого такая, автоматически созданная роль, имеет понятное для всех имя, формируемое по фиксированному шаблону.

Во-вторых, расширению конфигурации мы добавили новое свойство ИспользоватьОсновныеРолиДляВсехПользователей, которое стандартно установлено в значение Истина. Это значит, что по умолчанию при добавлении такого расширения все пользователи конфигурации будут обладать правами из основных ролей добавляемого расширения.

В третьих, в стандартную функцию Управление расширениями конфигурации мы добавили возможность управления основными ролями.

С её помощью пользователь, которому «доверено» администрирование расширений, может отобрать роли расширения у тех пользователей, которым оно не нужно. При этом автоматически будет сброшено свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей.

При необходимости и «ответственный» пользователь, и разработчик могут отдельно изменять значение этого свойства расширения. Пользователю оно доступно в списке расширений в стандартной функции Управление расширениями конфигурации, а разработчику оно доступно в списке расширений в Конфигураторе.

Таким образом, если вы не хотите использовать новое стандартное поведение (чтобы при добавлении вашего расширения все пользователи сразу же получали доступ к его функциям), устанавливайте свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей в значение Ложь. Тогда роли расширения, как и раньше, администратор должен будет добавить пользователям в явном виде.

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

По поводу использования основных ролей расширения хочется дать некоторые рекомендации.

Во-первых, среди основных ролей расширения могут быть только собственные роли, и эти роли не могут давать права на заимствованные объекты.

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

И, наконец, если в расширении нужен разный ролевой доступ к разным его частям, то в основную роль расширения добавляйте ту роль, которая понадобится большинству пользователей. А роль, которая даёт права на остальную функциональность, администратор добавит пользователям самостоятельно. Например, ваше расширение позволяет формировать и отправлять отчёты. Формировать могут все, а отправлять – только некоторые пользователи. Тогда роль, позволяющую формировать отчеты, вам нужно включить в основные роли расширения.

Мы надеемся, что новые возможности упростят вам создание и использование расширений конфигурации.

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

А если подробнее, то изменять вы можете любые модули, кроме модулей обычных форм:

Общие модули;
Модули объектов (модуль объекта, модуль менеджера и т.п.) для всех типов объектов;
Модуль сеанса;
Модуль управляемого приложения;
Модуль внешнего соединения;
Модули команд;
Модули форм;
и т.д.

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

Здесь и дальше, чтобы вам было проще читать, вместо словосочетания «процедура/функция» мы будем использовать слово «метод». Итак, все изменения, которые вы можете выполнять в модулях, можно разделить на 4 группы:

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

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

Собственные модули
Вы можете создавать в расширении собственные общие модули.

Вызов
И, наконец, вы можете вызывать в своём расширении любые методы типовой конфигурации.

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

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

Перехват вызовов методов

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

Необходимость перехвата того или иного типового метода вы полностью описываете в расширяющем модуле. Для этого мы ввели во встроенный язык новый структурный элемент – аннотацию. С помощью аннотации, расположенной перед определением метода, вы указываете, какой именно типовой метод перехватывает процедура/функция, и каким именно образом. Например:

Аннотация &Перед("Процедура1") означает, что перехватывается типовая процедура с именем Процедура1. Имя аннотации Перед означает, что сначала будет выполнена ваша процедура-перехватчик Расш_Проц1(), а затем - типовая Процедура1().

В настоящий момент мы добавили в платформу три возможных имени аннотаций.

Аннотация &Перед

Аннотация с таким именем означает, что ваш перехватчик будет выполнен до того, как начнётся выполнение типового метода.

На схеме типовой и расширяющий модули показаны прямоугольниками, а стрелка показывает последовательность исполнения встроенного языка.

Аннотация &После

Эта аннотация означает, что ваш перехватчик будет выполнен после того, как выполнится типовой метод.

Аннотация &Вместо

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

На одну и ту же типовую процедуру вы можете установить в своём расширении одну из следующих комбинаций перехватчиков:

&Перед;
&После;
&Вместо;
&Перед и &После.

Последняя комбинация перехватчиков (&Перед и &После) будет исполняться следующим образом:

Если же вы перехватываете типовую функцию, а не процедуру, то вы можете использовать только перехватчик &Вместо.

Вызов метода, перекрытого аннотацией &Вместо

Получается некоторая несправедливость. Процедуру вы можете перекрыть или обрамить. А функцию – только полностью перекрыть.

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

На встроенном языке такая функция-перехватчик может выглядеть следующим образом:

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

Метод ПродолжитьВызов() вы можете использовать не только при перекрытии функций, но и при перекрытии процедур. В этом случае результат его применения будет по смыслу такой же, как при использовании пары перехватчиков &Перед и &После. Разница будет лишь в том, что в этом случае ваша часть «до» и ваша часть «после» будут существовать внутри одного контекста. В некоторых ситуациях это может быть удобно. На встроенном языке такая процедура-перехватчик может выглядеть следующим образом:

Что лучше, &Перед, &После или &Вместо?

Когда вы перехватываете методы типовой конфигурации, всегда полезно помнить о двух вещах:

После того, как вы написали своё расширение, типовая конфигурация будет изменяться;
Ваша цель – добавить свою функциональность, а не навсегда отказаться от того, что есть, и что будет в типовой конфигурации.

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

Также вполне приемлемым является использование перехватчика &Вместо и метода ПродолжитьВызов(). Однако тут у вас появляется возможность и соблазн вызывать типовой метод не всегда, а в зависимости от каких-то своих собственных условий. К этому нужно подходить осторожно и помнить, что в тот момент, когда вы отказываетесь от вызова типового метода, вы отказываетесь от вызова не только того метода, который есть в конфигурации сейчас, но и от всех его вариантов, которые появятся в будущем. А в будущем, например, в нём могут появиться важные и полезные изменения.

И, наконец, самый «нехороший» вариант – это полное перекрытие типового метода перехватчиком &Вместо. В этом случае типовой обработчик безусловно не будет выполняться ни сейчас, ни в будущих версиях. То есть всю ответственность за работу будущих версий конфигурации вы берёте на себя, на своё расширение. Наверняка есть ситуации, когда такое полное перекрытие необходимо, но мы призываем вас подходить к его использованию очень взвешенно и осторожно.

Последовательность вызовов при перехвате методов

Здесь, прежде чем рассказывать, необходимо сделать небольшое пояснение. Важной, можно сказать, «идеологической» характеристикой расширений является их автономность. То есть расширения должны проектироваться так, чтобы не зависеть друг от друга.

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

Когда вы подключаете расширения к типовой конфигурации, образуется «многослойный пирог». В основании этого пирога находится типовая конфигурация, а на его вершине – последнее подключенное расширение.

Что в конфигураторе, что в режиме 1С:Предприятие, последнее подключенное расширение находится в списке последним.

Таким образом, в этом примере внизу находится типовая, наверху находится Расширение2, а между ними – Расширение1. Каждое следующее расширение перехватывает (расширяет) то, что находится под ним.

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

Пример 1

Например, если в двух расширениях перехвачен (обрамлён) один и тот же типовой метод, то последовательность вызова обработчиков будет следующая:

Сначала будет вызван перехватчик из Расширения2, потому что оно сверху. Это будет перехватчик &Перед, потому что у него такая аннотация;
Затем будет вызван перехватчик из Расширения1, потому что оно следующее в пироге. Это будет снова &Перед, потому что у него такая аннотация;
После этого будет вызван типовой метод, потому что больше нет перехватчиков, препятствующих его исполнению;
Затем, в обратной последовательности «пирога», будут вызваны перехватчик &После из Расширения1 и перехватчик &После из Расширения2.

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

Пример 2

Если в перехватчиках используется метод ПродолжитьВызов(), то действует тот же самый принцип «пирога».

Сначала будет вызван перехватчик из Расширения3, потому что оно сверху. Это будет перехватчик &Вместо, потому что у него такая аннотация;
При попытке вызвать типовой метод, будет анализироваться оставшийся «пирог». Анализироваться он будет точно таким же образом, как было описано в предыдущем примере;
В результате исполнение кода вернётся в перехватчик &Вместо, а по его завершении – в типовую конфигурацию.

Пример 3

Важным для понимания моментом является тот факт, что при перекрытии с помощью аннотации &Вместо, по факту перекрывается не только вызов основного метода, но также и перехватчиков, находящихся ниже в «пироге».

В этом примере будет выполнен только перехватчик &Вместо из Расширения2. Потому что он перекрывает собой типовой метод, то есть весь «пирог», который находится под ним.

Пример 4

Это, по сути, вариация на тему второго примера, но когда под верхним расширением находится расширение, также «прокидывающее» вниз вызов типовой процедуры.

По сути, он просто лишний раз визуализирует тот факт, что вызов типового метода относится ко всему «пирогу», находящемуся под расширением. Именно поэтому после вызова перехватчика из Расширения2, будет вызван перехватчик из Расширения1. Потому что в оставшемся «пироге» именно он перекрывает вызов типового метода, до которого хочется «дотянуться» Расширение2.

Перехват обработчиков событий и собственные обработчики в модулях объектов, менеджеров и т.п.

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

Во-первых, в качестве имени перехватываемого метода указывается имя события. Например, ПередЗаписью:

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

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

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

Перехват любых методов в этих модулях тоже выполняется точно так же, как было описано в начале. Однако и тут есть особенности, связанные с перехватом обработчиков событий. Эти особенности связаны с тем, что в этих модулях все обработчики событий назначаемые, и не имеют фиксированных имён. Как вы наверняка знаете, чтобы платформа понимала, чем нужно обрабатывать то или иное событие, в конфигураторе, в панели свойств, должна существовать привязка конкретной процедуры к конкретному событию.

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

Внешне перехватчик события в модуле формы выглядит следующим образом:

То есть аннотация не используется, а тип перехватчика указывается в палитре свойств. Делается это довольно просто. При создании в расширении обработчика по кнопке «лупа» открывается диалог. Он позволяет вам, помимо контекста, указать тип перехватчика (Перед, После или Вместо).

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

Если вы перекрываете типовой обработчик (Вместо), то это будет просто точка.

Если вы создаёте перехватчик Перед или После, то это будет точка рядом с вертикальной чертой. Местонахождение точки, перед или после черты, обозначает тип перехватчика. А кроме этого в палитре свойств появляется второе (пустое) поле рядом с этим событием. С его помощью вы можете задать парный перехватчик, если есть необходимость обрамить типовой обработчик парой Перед - После.

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

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

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

Общие модули

В расширении вы можете создавать любые собственные общие модули. Существует только два ограничения:

Они не должны быть глобальными серверными;
Они не должны быть привилегированными.

Когда вы расширяете общий модуль типовой конфигурации, тоже есть аналогичные ограничения:

Нельзя заимствовать глобальные серверные модули;
Код из вашего расширения будет исполняться только в непривилегированном режиме (если иное не разрешено в профиле безопасности).

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

Серверные методы расширяются не всегда

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

Если прикладное решение работает в файловом варианте или в клиент-серверном варианте без профилей безопасности, то при подключении вашего расширения:

В обычном режиме исполнения встроенного языка - будут расширяться все методы типового решения, и клиентские, и серверные;
В безопасном режиме исполнения встроенного языка - будут расширяться только клиентские методы и серверные обработчики форм. К остальным серверным процедурам / функциями расширение применяться не будет.

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

Для этого в профиль безопасности мы добавили несколько новых свойств.

Самое простое из них – это флажок к расширению всех модулей в группе Разрешен полный доступ. Он «одним махом» разрешает расширение серверного контекста.

Есть и более точная настройка с помощью полей Доступные для расширения модули и Недоступные для расширения модули. Мы предполагаем, что вы будет использовать их следующим образом:

Читайте также: