Связи параметров при вводе ссылочных данных

[unpete]

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

Верхушка решения очень простая - расширяем тип поля Ведомый справочника СвязиПараметров, чтобы в нём можно было указать не только ссылку на Дополнительный реквизит, но и строку - полный путь к данным (например, dp.buyers_order.production.inset - поле Вставка табчасти Продукция обработки Заказ покупателя) и вуаля - дело в шляпе. Эта связь начнёт ограничивать выпадающий список в поле ввода и динамический список в форме выбора, открытой из этого поля.

[unpete]

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

[unpete]

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

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

Элемент справочника Связи параметров ничего не знает про метаданные - он управляет списком значений дополнительных реквизитов. Разница между обычным и дополнительным реквизитом довольно большая (огромная, но я не писатель и не готов 300 страниц про это). Ключевое различие: у реквизита есть путь, а у допреквизита (как элемента плана видов характеристик), пути нет (его можно воткнуть в любой объект). Список путей мы можем перечислить в новом справочнике ПараметрыВыбора

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

[unpete]

В 1С есть "параметры выбора" и "связи параметров выбора" - они задаются в конфигураторе и не имеют доступа к данным (только предопределенные значения) Наши параметры выбора, оказывают такое же влияние на интерфейс, но вместо статического отбора на равенство, могут использовать любые формулы и любые данные (папки, ссылки, выражения)