Каталог решений - О расширениях замолвите слово…

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

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

1. Не дробить расширения для одного и того же объекта конфигурации
2. Изменения расширяемых форм делать программно, а не через редактор форм
3. Минимизировать использование аннотации &Вместо (&ИзменениеИКонтроль?)
4. Делать независимые друг от друга расширения
5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
6. Вести реестр расширений

Рассмотрим подробнее каждый пункт

1. Не дробить расширения для одного и того же объекта конфигурации.

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

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

2. Изменения расширяемых форм делать программно.

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

Давайте возьмем самый банальный пример: сделать определенное поле на форме нередактируемым, т.е. установить ему свойство "ТолькоПросмотр".

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

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

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

Тогда первичная простота во второй раз может превратиться в затратную по времени процедуру и, возможно, это будет повторяться неоднократно.

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

Так что же делать? Всё просто! Любые изменения, связанные с элементами формы делайте программно, вообще старайтесь не трогать редактор форм, как бы соблазнительно это не было. Либо альтернативный вариант решения: к каждому расширению прикладывать подробное описание: что и с каким элементом Вы сделали, какое свойство поменяли, какой элемент добавили и т.п.

Не рекомендуется делать так:

Рекомендуется: добавить процедуру с аннотацией &После для события формы "ПриОткрытии" примерно с таким кодом:

&НаКлиенте
Процедура АТБ_ПриОткрытииПосле(Отказ)
   Элементы.Ответственный.ТолькоПросмотр = Истина;
   // и все другие изменения элементов формы
КонецПроцедуры

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

В случае затруднений при программном изменении элементов форм можно воспользоваться бесплатным инструментарием декомпиляции формы, который публиковался здесь на Инфорстарте Евгенией Карук — Генерация кода управляемой формы (т.е. сначала делаем форму в редакторе, указанным инструментом декомпилируем ее и смотрим, как делаются элементы формы программно).

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

3. Минимизировать использование аннотации &Вместо.

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

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

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

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

Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)

Например, раньше (т.е. сейчас, пока не обновили платформу) нам приходилось писать так: