Этот функционал представлен следующим блоком общих модулей (разбивка на наш взгляд):
1) События форм. Этот блок представлен двумя общими модулями - «События Форм» и «События Форм Клиент».
Если вернуться в статьям о механизмах минимального изменения конфигураций, то эти два модуля позволяют разместить динамически элементы и обработчики на форме и обрабатывать их. В модуле «События Форм» находится процедура «ПриСозданииНаСервере», которая вызывается из практически каждой формы в функции формы «ПриСозданииНаСервере». Соответственно в ней удобно разместить код позволяющий создавать динамически элементы на формах и обработчики событий этих форм. К примеру, можно это сделать следующим образом:
Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;
Однако разработчики предложили перенести этот код в общий модуль «МодификацияКонфигурацииПереопределяемый». И из процедуры идет еще один вызов:
МодификацияКонфигурацииПереопределяемый.ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка);
Для отработки динамических команд элементов практически в каждой форме добавлена только одна обезличенная процедура Подключаемый_ВыполнитьПереопределяемуюКоманду, обрабатывать события предлагается в специальных общих модулях – «События Форм Клиент». Решение элегантное. С общим модулем «События Форм Клиент» ситуация аналогичная, в нем происходит перевозов процедуры.
2) Модификация конфигурации. Этот блок представлен следующими общими модулями:
«Модификация Конфигурации Вызов Сервера Переопределяемый», «Модификация Конфигурации Клиент Переопределяемый», «Модификация Конфигурации Клиент Сервер Переопределяемый», «Модификация Конфигурации Переопределяемый».
В каждой форме документа коллеги вставили следующий код для поддержки механизма модификации конфигурации. На серверной части:
- В процедуре «ПриСозданииНаСервере» вызывается «СобытияФорм.ПриСозданииНаСервере»;
- В процедуре «ПриЧтенииНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПриЧтенииНаСервере»;
- В процедуре «ПослеЗаписиНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПослеЗаписиНаСервере»;
- В процедуре «ПередЗаписьюНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПередЗаписьюНаСервере»;
На клиентской части:
- В процедуре «ПослеЗаписи» вызывается функция «МодификацияКонфигурацииКлиентПереопределяемый.ПослеЗаписи»;
- И универсальная процедура для обработки событий для всех элементов формы на клиенте «Подключаемый_ВыполнитьПереопределяемуюКоманду».
Для обработки действий связанных с инициализацией, обработкой событий необходимо провести проверку по условию принадлежности к той или иной форме. Для этого необходимо воспользоваться свойством наименование управляемой формы, к примеру, сделать это в следующем виде:
Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;
И для обработки команд дополнительное условие:
Если Команда.Имя= «Команда_Х» Тогда
ИначеЕсли ….
КонецЕсли;
3) Особенности. К особенностям можно отнести некоторые специфические моменты.
Во-первых, пока не во всех формах и списках добавлена поддержка этого механизма. Вполне возможно, что в бедующих релизах этот пробел будет восполнен.
Во-вторых, в некоторых случаях разработчики сами используют блок динамической инициализации обработчиков изменений элементов. При первоначальном включении в их блок мы сперва очень удивились, что почему-то некоторые наши обработчики не совсем адекватно и не всегда отрабатывают в некоторых документах. Объяснение этому простое, как оказалось для документов в которых используется механизм согласование: Заказ Клиента, Реализация Товаров и Услуг и др.; используется динамическое создание подписок на события изменения элементов, которое происходит после нашей точки инициализации (в процедура При создании на сервере). На сброс флага согласован влияет множество изменений реквизитов и чтобы не обрабатывать каждый реквизит в отдельности они создают динамическую привязку события изменения к одной функции. К тому же эта операция происходит не всегда, а зависит от статусов документа.
В связи с этим при данную ситуацию необходимо обрабатывать самостоятельно, если у вас есть необходимость повестить свою обработку событий на эти реквизиты.
Зато можно воспользоваться готовой встроенной функцией для установки подписки на событие элемента формы:
ОбщегоНазначенияУТ.УстановитьПодпискуНаСобытияИзмененияЭлементовФормы(ЭтаФорма, МассивЭлементов, УстановитьПодписку);
В третьих, не все случаи по прежнему удается обрабатывать данным нововведением. Хотя это уже большой плюс. И мы выражаем глубокий респект разработчикам конфигурации ERP 2.0 за такую возможность.
4) Бонус. Правила которые мы используем при доработках типовых конфигураций.
a) Добавление своих объектов метаданных с префиксом. Мы добавляем префикс в таком формате «DI_»+наименование объекта. Иногда используется вариант добавления префикса поле наименования: наименование объект+ «DI»; но этот вариант менее нагляден. Для дополнительной фильтрации новых объектов создается своя подсистема, в которую включаются все новые объекты.
b) Добавление своих реквизитов к существующим объектам метаданных. Мы используем добавление реквизитов по аналогии с добавлением своих объектов: «DI_»+наименование реквизита.
c) Изменение форм объектов. Изменение форм объектов и подписок на элементы осуществляем динамически. Также уже используем технологию, о которой говорится выше. В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.
d) Использование модификаций запросов. В связи с нововведениями в версии платформы 8.3.5, а именно: конструктор запросов в управляемом приложении и объектная модель схемы запроса - появилась возможность более удобно вносить модификации в запросы. Если ранее пользователь создавал рваный запрос или использовал функцию СтрЗаменить, то теперь достаточно использовать объектную модель. К примеру, добавить в исходный запрос новое поле в выбранных полях:
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Запрос.Текст);
//при создании схема содержит один пакет и один оператор в пакете.
Пакет = СхемаЗапроса.ПакетЗапросов[0];
Оператор = Пакет.Операторы[0];
Оператор.ВыбираемыеПоля.Добавить(«РеализацияТоваровУслуг.Ссылка»);
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();
Ожидаем использование подобного механизма в скором будущем в текущих типовых конфигурациях.
e) Использование подписок на события. Мы используем подписки на события для дополнительных проверок, формирования своих движение и т.д. В этом случае создается необходимая подписка на событие и формируется код проверки. Позволяет не вносить изменение в типовой функционал.
f) Использование дополнительных команд. Для увеличения удобства интерактивной работы с нашими доработками довольно часто используем данный механизм.
g) Поиск точки минимального изменения или воздействия. Прежде чем вносить изменения согласно задания на доработку ищем в коде тот участок, при изменении в котором понадобится минимальное число исправлений. Как вариант возможно переписывания какой-то функции целиком.
h) Добавление реквизитов в регистры. При добавлении изменений в регистры мы поступаем по следующему правилу. Если это регистр накопления оборотный, то можем смело добавить измерение. Если это регистр накопления остатков, то в данном случае стараемся не вносить изменения в измерения и ресурсы, а создать свой новый регистр остатков. Если затрагивает реквизиты, то в данном случае можно выполнять эту операцию без проблем.
i) Комментарии и документация. При внесении изменений мы обязательно делаем комментарии, указывая Автора, Дату, Задачу, Пояснения, вход и выход изменений. Дополнительно вносится информация в реестр изменений с такими же параметрами.
j) Использование средств командной разработки. Мы используем механизм хранилище конфигурации, систему баг-трекинга, трёхуровневое тестирование – внутренне тестирование разработчиком, тестирование таксировщиком самостоятельно и по кейсам и внешнее тестирование представителем от заказчика.
k) Техническое задание. Хорошей практикой является формализация требований к доработкам. Они могут
l) Другие правила.
