• Добавить свою публикацию
для этого требуется регистрация

Кузнец Никула

06.02.2013

Программисту > Приемы работы

+2

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

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

Одним из выходов также является хранение элементов справочника в константах. Например, создать столько констант, сколько различных тип цен будет использоваться в механизмах конфигурации. Однако этот метод приемлем лишь с малым количеством элементов. А представьте, если количество справочников, в которых нужно запоминать элементы, достигнет нескольких десятков? Тогда количество констант может неимоверно разрастись!

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

Предлагаемое решение

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

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

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

Функция ВернутьЗначениеПредопределенногоЭлемента(ИмяЭлемента)
 Запрос =Новый Запрос;
 Запрос.Текст =
 "ВЫБРАТЬ
 |ПредопределенныеЭлементы.Значение
 |ИЗ
 |Справочник.ПредопределенныеЭлементы КАК ПредопределенныеЭлементы
 |ГДЕ
 |ПредопределенныеЭлементы.Ссылка = &ПредопределенныйЭлемент";

 ПредопределенныйЭлемент = ПредопределенноеЗначение("Справочник.ПредопределенныеЭлементы."+ ИмяЭлемента);
 Запрос.УстановитьПараметр("ПредопределенныйЭлемент",ПредопределенныйЭлемент);

 Выборка = Запрос.Выполнить().Выбрать();
 Выборка.Следующий();
 Возврат Выборка.Значение;
КонецФункции

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

Ниже показан пример связки элементов в пользовательском режиме.

Вместо вывода

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