Skip to content

Latest commit

 

History

History
41 lines (33 loc) · 8.61 KB

useexts.md

File metadata and controls

41 lines (33 loc) · 8.61 KB

Применение расширений

При доработке (адаптации) типовых конфигураций допускается использование расширений СОВМЕСТНО с внесением изменений в конфигурацию. Необходимость использования расширений оговаривается для конкретного проекта. Варианты расширений:

  1. Для доработки типовой конфигурации создается ОДНО основное расширение на конфигурацию, оно подключается к хранилищу расширений. Далее идет описание правил работы именно с ним;
  2. Отдельные расширения для временного решения определенных проблем (патчи), если недопустимо оперативное изменение основной конфигурации. Они не подключаются к хранилищу;
  3. Отдельные расширения для разработки обособленных подсистем.

Основное назначение расширения - упростить последующее обновление доработанной типовой конфигурации до актуальных версий. Если необходимо расширить или заменить типовые события/процедуры, следует руководствоваться следующими приоритетами: А) Реализовать подписку на событие Б) Реализовать в расширении В) Изменить типовой модуль.

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

  1. Выполнять доработку типовых форм, модулей, состав подсистем предпочтительно в расширении. При этом в расширение следует выносить только нужные объекты.
  2. Добавление новых объектов метаданных (справочники, реквизиты и т.д.) необходимо делать в основной конфигурации! В расширении только изменение типовых модулей, форм, макетов и т.д. 2.1. Новые собственные объекты добавляем в основную конфигурацию и в ней же дорабатываем. Например, новый документ грПремияКоДнюЭнергетиков и все его реквизиты, формы, макеты и т.д. добавляется в основную конфигурацию. 2.2. Новые реквизиты для типовых объектов необходимо добавлять в основную конфигурацию. Например, если необходимо в типовой документ «Премия» добавить реквизит грКомментарий, то добавляем реквизит в основную конфигурацию и затем используем его в модулях или при доработке формы в расширении. 2.3. При редактировании в расширении текста запросов с использованием конструктора он "ругается", если всех таблиц запроса нет в расширении. Добавлять объект в расширение только ради этого (чтобы использовать конструктор запросов) НЕ НАДО! особенно, если запрос использует множество объектов. Можно отредактировать текст запроса конструктором в другом модуле (например, во внешней обработке) и потом перенести в расширение. Количество объектов в расширении должно быть минимально необходимым.
  3. Приоритетным является использование префиксов &Перед или &После для доработки процедур. При расширении для функций используется единственный префикс &Вместо. Но с его помощью можно реализовать ту же логику работы, как Перед и После с помощью конструкции ПродолжитьВызов() без копирования полного текста процедуры в расширение. Например:
&Вместо("ОтборСотрудниковДляВыплаты")
Функция РасшЗУП_ОтборСотрудниковДляВыплаты()
	
	Параметры = ПродолжитьВызов();
	
  // тут реализована логика работы ПОСЛЕ
	// +++ Градум, Утешев Д.В [11.06.2019] ОПЭ_232
	Параметры.Вставить("ВыплатыВПользуФизическихЛиц",   Ложь);
	// +++ Градум, Утешев Д.В [11.06.2019] ОПЭ_232
	
	Возврат Параметры;
	
КонецФункции
  1. Отдельное замечание про доработку в расширении типовых процедур, функций с префиксом &ВМЕСТО с копированием текста процедуры. Эту возможность следует использовать взвешенно и обоснованно из-за необходимости адаптации этих доработок при обновлении релиза типовой конфигурации. Например, если процедура в расширении значительно переписывается и обновлению уже не подлежит, то можно использовать &Вместо. В тех случаях, когда требуется внести локальное изменение только в часть процедуры и при этом не меняется основной её алгоритм, то лучше внести изменение в основную конфигурацию. Спорные случаи согласовывать с архитектором. В любом случае все изменения внутри типовых процедур (не важно в расширении или нет) нужно комментировать по общим правилам!
  2. Добавление новых РОЛЕЙ необходимо выполнять в основной конфигурации. Типовые Роли в расширении по возможности не дорабатывать (т.к. эти изменения потом сложно анализировать и адаптировать при обновлении конфигурации). Решать задачи добавлением новых ролей основной конфигурации там, где это возможно. Необходимость доработки типовых ролей (не важно в расширении или нет), необходимо согласовывать с архитектором.
  3. Доработки расширения разработчиками ведутся в ХРАНИЛИЩЕ расширений по правилам, описанным в "Правила работы с хранилищем".
  4. Если какая-либо из исходных типовых форм расширена - не следует в расширении злоупотреблять "визуальным конфигурированием" формы (перемещать группы и кнопки, добавлять или удалять элементы и команды). Все изменения расширенной формы следует делать программно (см. раздел Доработка форм в Общие требования по доработке типовых конфигураций на платформе 1С Предприятие 8)