1с динамический список развернуть группировки
Обновлено: 08.07.2024
Эффективность методики зависит от структуры справочника и количества записей в нем. Понятное дело - что если справочник мал, и при установке в палитре свойств таблицы формы свойства НачальноеОтображениеДерева в РаскрыватьВсеУровни он открывается за секунду, то тут эффект не будет заметен. Однако все изменяется с ростом количества элементов. Ниже приведены результаты тестирования. Помимо полного разворачивания разработана и процедура для полного сворачивания.
Для тестирования старался выбирать разноплановые справочники (разные по типу иерархии, количеству элементов и групп / родителей)
1 колонка - наименование справочника
2 колонка - количество элементов
3 колонка - количество групп / родителей
4 колонка - время на раскрытие методом установки в палитре свойств таблицы формы свойства НачальноеОтображениеДерева в РаскрыватьВсеУровни
5 колонка - время на раскрытие с помощью моей методики
Для клиент-серверной версии:
| Справочник | Элементов | Групп/родителей | Стандартно | С оптимиз. |
| Контрагенты | 7809 | 6 | 27 с | 0,6 с |
| Банки | 17465 | 78 | 52 с | 5 с |
| Статьи движения ДС | 124 | 32 | 3 с | 2,1 с |
| Подразделения организаций | 73 | 17 | 4 с | 1,5 с |
Повторные разворачивания всего дерева в течение сеанса работы происходит за доли секунды (если вы не закрывали окно справочника).
Суть оптимизации состоит в нахождении КЛЮЧЕВЫХ узлов, раскрытия которых абсолютно достаточно для полного раскрытия всего дерева. А исходя из того, что стандартным механизмом 1С раскрываются полностью все узлы, в т.ч. и подчиненные элементы, то выигрыш в количестве обращений к серверу, а соответсвенно и во времени разворачивания дерева очень существенный (особенно заметно на больших справочниках).
Методика (корректировка). Код и описание методики в модуле объекта обработки.Специальные предложения
Полное отсутствие информации о методах решения задачи дает обратный эффект. Не заинтересовывает.
Хотя бы в общих чертах и сжато но описание подхода нужно.
Иначе давайте все статьи будем назвать "Кто-то сделал что-то" и прикреплять файлы. Пусть инфостарт развивается! (6) Даже не знаю что и ответить. Подождем для начала комментариев от тех, кто воспользовался методикой. О достигнутом эффекте. Присоединяюсь к (6). В таком виде публикация выглядит как реклама от перхоти. Поделитесь хотя бы оценкой трудоемкости прививки данной методики к готовым конфигурациям. Ну что-то вроде "добавить три процедуры в общий модуль и внести их вызовы в 2315 мест в формах справочников". Суть самой методики, так и быть, не раскрывайте. Ну, и еще просьба. Если кто скачал и использовал методику - то было бы очень хорошо, если бы в комментах написали какой выигрыш во времени раскрытия дерева получили (или не получили). Возможно большая выборка результатов даст повод попробовать еще больше оптимизировать процесс. Хотя на первый взгляд дальше уже некуда. . рискну выразится несколько резко. однако даже после скачивания файла - не совсем понятен принцип действия, тем более, что чтобы опробовать методику требуется некая доработка Вашей обработки. Если уж Вы не предоставили описание методики, выложите хотя-бы готовую обработку, которую можно было бы запустить в конфигурации без её изменения (выпустите некий "окончательный продукт", не требующий "допиливания"), понимаю, что на это потребуется чуть больше времени, но все же попробуйте, и, возможно повысите свой статус, до уровня "когда $m уже не важны" ))). Неплохо бы в общих словах и описать принцип действия.
(9) Принимаю любую критику - так что не проблема
Для начала поясню - это не обработка, а процедуры и функции + пояснения по их внедрению в вашу конфигурацию. Просто для удобства и скажем так ради "боевой раскраски" они упакованы не в текстовый файл, а в общий модуль обработки.
И невозможно сделать готовую обработку (дело не во времени). В любом случае придется вносить изменения в конфигурацию. Хотя бы создать кнопки Свернуть и Развернуть.
Ну а это выдержка из текста модуля обработки:
//Создаем в любом общем модуле с установленным свойством Клиент(Управляемое приложение)
//(остальные свойства в Ложь) либо создаем свой общий модуль с описанными выше свойствами.
//В моем случае это общий модуль РазворачиваниеСворачиваниеДереваКлиент.
//В нем создаем экспортную процедуру:
Далее текст самой процедуры
//Создаем в любом общем модуле с установленным свойством Сервер
//(остальные свойства в Ложь) либо создаем свой общий модуль с описанными выше свойствами.
//В моем случае это общий модуль РазворачиваниеСворачиваниеДереваСервер.
//В нем создаем экспортную функцию:
Далее текст самой функции
//Далее в модуле управляемой формы списка целевого справочника создаем 2 процедуры и 2 функции:
Далее тексты процедур и функций
//Готово. Теперь в палитре свойств списка справочника устанавливаем Отображение = Дерево,
//НачальноеОтображениеДерева = НеРаскрывать.
//А далее по желанию либо в каком-нибудь событии формы вызывать РазвернутьВсе() или СвернутьВсе()
//либо (как это реализовано у меня) создать две соответствующие команды, разместить их
//в командной панели формы, а в их обработчиках вызывать соответствующие процедуры (РазвернутьВсе() или СвернутьВсе()).
Вот интересно - что здесь непонятно?
Ну, и заодно очевидна и "трудоемкость прививки к готовым конфигурациям" для (8).
А $m мне действительно не важны, сколько их уже есть - мне столько обработок не понадобится - факт.
Количество скачиваний файла мне пусть и субъективно но показывает количество человек кому необходима такая методика. А возможно, с некоторой скидкой, и кому в итоге помогла. Т.е. если я вижу ее не бесполезность, то тогда есть желание дальше работать в этом направлении - в том смысле, что разрабатывать нечто, что может быть полезным другим.
(11) Каким образом для пользователя подмените стандартную форму списка на свою обработку не внося правки в конфигурацию?
Но суть даже не в этом - я нигде и не писал, что это готовая обработка. Я обозначал, что это методика. И в (10) я объяснил причину ее "упаковки" в обработку. Методика готовая к использованию. Все функции и процедуры написаны, их нужно только внедрить в свою конфигурацию.
(12) если "въеду" в Вашу методику, напишу такую обработку. Методика работает только в "стандартной форме списка"? По крайней мере в пределах обычных форм на форму внешней обработки можно "положить" Форму списка любого справочника. (13) Методика работает в любой форме с динамическим списком отображаемым в виде дерева. В пределах обычных форм (если Вы под обычными имеете в виду не управляемые) смысла в этой методике нет абсолютно.И понятное дело, что в управляемых формах можно в форму обработки "положить" список любого справочника. Только как Вы будете подменять стандартную форму справочника на Вашу из обработки не влезая в конфигуратор (если у Вас конфигурация на полной поддержке)? (14) в большинстве случаев интересно применение ускорения именно в нестандартных формах справочников, как-то например, подбор номенклатуры в УТ11 (Управляемые формы). В УТ11 "подбор в документ продажи" реализован обработкой. Я имел ввиду, что для иллюстрации выигрыша можно сделать внешнюю обработку, скажем по одному и тому-же справочнику, стандартным способом, и Вашим, возможно в одной форме по типу "Norton Commander" С интересом прочитал обсуждение.
Видно, что в публикации изначально не хватало:
- указания из (15), что "смысла в этой методике нет в режиме обычного приложения"
- картинки, которая бы сразу показала вид развернутого дерева.
Теперь (наконец) стало ясно, необходима ли мне такая методика.
(39) Да бросьте - изначально в заголовке публикации было указано "управляемый интерфейс" :)
(38) Теперь я понял о каких двух вариантах шла речь. И теперь утверждать то, что реализовал оба варианта конечно же не буду. Изначально в описании публикации я говорил о конкретном варианте - одном списке в виде дерева.
Ваша функция с запросом и с последующей обработкой отрабатывает быстрее моей, пусть даже и та и другая выполняется за доли секунды - но отрицать факт неоптимальности моей реализации нет смысла.
Также возьму на заметку организацию запроса и обработки для двух списков. Спасибо.
Еще раз отмечу - что публиковалась методика, т.е. идея. А ее реализовывать можно по разному. Моя реализация - не оптимальна. И рад, что тема вызвала такое обсуждение, пусть и лишь с участием нескольких человек.
Ну и попрошу одного пояснения - у Вас все, что было Вами написано в этом обсуждении уже было реализовано до появления этой публикации или нет?
Т.е. мне интересно идея КЛЮЧЕВЫХ узлов была для Вас нова, или нет? (просто помню обсуждение подобной темы на мисте, где Вы говорили, что иерархический справочник из 5 000 строк открывался более 3 минут)
А меня ещё больше, чем возможность использования ссылки в качестве параметра, удивил сам результат применения метода "Раскрыть" к глубоко вложенным ветвям дерева. Никогда бы не подумал, что при этом раскроются все родительские узлы. Я считал, что в этом случае просто запомнится состояние данного узла во внутренних переменных.
И вот что в связи с этим я для себя при этом обнаружил. Если на форме размещается дерево (полученное, например, запросом), то в нём запоминается состояние "раскрыт" для дочерних узлов. Т.е. если закрыть и заново открыть родительский узел, то его дочерние узлы будут раскрыты или закрыты в зависимости от того, какими мы их оставили. А в динамическом списке в виде дерева этого нет. Хотя, если задуматься, то понятно почему. (41) Признаю, был неправ, не дочитал конец заголовка, а чуть ниже - многочисленные "не имеет значения" в рубрикаторе - ввели в меня заблуждение.
Но картинку все ж надо было приделать. (49) К сожалению нету рубрикатора для указания типа интерфейса или приложения. Ну и еще - стандартного метода раскрыть все дерева после того как форма создана и выведена на экран - нет. Во всяком случае я его не знаю. Поэтому только выставлять свойство списка НачальноеОтображение = РаскрыватьВсеУровни.
Ну вот писал, писал - все куда-то ушло в корзину. Поэтому повторю. Если вдруг появится предыдущий труд - извиняйте.
Итак попробовал данный вариант. Сначала цифры: Справочник "Материалы" - количество записей 40 093 из них 379 папок. Время разворачивания списка: 1-е 50 сек., последующие 8 сек. Время сворачивания: 4 сек. Время разворачивания справочника при открытии в режиме "Разворачивать все уровни" 4 мин. 50 сек.
Теперь по методике: ничего нового или оптимизирующего в ней нет. Единственное что для себя открыл (до этого не пробовал писать не в соответствии с документаций) так это то, что в метод Развернуть(Строка,СПодчиненными) и Свернуть(Строка) можно передать в параметр "Строка" - ссылку а не идентификатор строки, как это написано в документации:
ТаблицаФормы (FormTable)
Развернуть (Expand)
Синтаксис:
Развернуть(<ИдентификаторСтроки>, <СПодчиненными>)
Параметры:
Тип: Произвольный.
Идентификатор строки таблицы.
<СПодчиненными> (необязательный)
Считаю это недоработкой документации.
Разжую для тех кто не сразу въезжает в тонкости данной темы:
По данной методики можно только организовать полное сворачивания и разворачивания веток дерева для динамического списка (в принципе можно модифицировать для разворачивания до определенного уровня). Все делается стандартными методами объекта "ТаблицаФормы": Развернуть() и Свернуть().
С вышесказанными замечаниями относительно параметров этих методов никаких сложностей с реализацией данных действий не возникает. Для динамических списков не возможно получить строку(и) из формы, которые нужно свернуть или развернуть, как например, для дерева( методом ДанныеФормыДерево.ПолучитьЭлементы()) - и потом уж получить по этим элементам идентификатор строки, который следовало бы передавать в качестве строки в метод Развернуть(). Оказывается вместо этого можно просто передать ссылки справочника. В этом и суть всех действий, предлагаемых автором. Все остальное стандартно. Ссылки получает запросом на сервере (кстати сам текст запроса какой-то геморный, не понял зачем так делать, но об этом позже), и потом обходя полученные ссылки разворачивается или сворачивается ветка ТаблицыФормы (списка справочника) из динамического списка методом Развернуть()/Свернуть(), где в качестве ссылки передается не идентификатор строки, а сама ссылка.
Теперь по поводу начального режима дерева: стоит устанавливать "Разворачивать только верхний уровень" - на моей базе разницы во времени с режимом "Не разворачивать" вообще никакой. Но хоть что-то отображается, вместо просто наименования справочника.
Теперь по поводу запроса: зачем там такой алгоритм - не понял. Переделал на простенький вариант:
Функция ПолучитьСписокЭлементовДерева2(ИмяСправочника, Развернуть) Экспорт
Запрос = Новый Запрос();
Запрос.Текст + ИмяСправочника + ".Ссылка
|ИЗ
| Справочник." + ИмяСправочника + " КАК " + ИмяСправочника + "
|ГДЕ
| " + ИмяСправочника + ".ЭтоГруппа"+?(Развернуть,""," И "+ИмяСправочника + ".Родитель = ЗНАЧЕНИЕ(Справочник." + ИмяСправочника + ".ПустаяСсылка)");
СписокЭлементов = Новый СписокЗначений;
СписокЭлементов.ЗагрузитьЗначения(Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка"));
Возврат СписокЭлементов;
КонецФункции
Некоторое пояснение: для сворачивания нет необходимости получения всех групп, достаточно свернуть только группы на верхнем уровне.
Ну и теперь размышления по поводу производительности разворачивания(сворачивание всегда идет более менее быстро). В общем-то можно организовать 2-мя способами: разворачивать только верхний уровень с подчиненными, что делать не стоит (на моей базе в этом случае время разворачивания составляет 3 мин 50 сек - то, есть тоже самое, что режим при открытии разворачивать все уровни)! или разворачивать все ветки, следует использовать данный вариант. Разница во времени показывает качество оптимизации (вернее ее полное отсутствие) для дерева в 1С.
При разработке форм подборов и организации отборов для удобства работы может возникнуть задача по автоматическому раскрытию текущей группы.
- упростить работу пользователю, выполнять 1 клик вместо 2;
- явно дать понять ему, что есть вложенные группы.
В такой простой задаче может возникнуть стопор из-за особенностей динамического списка:
- в метод Развернуть() таблицы формы следует передать идентификатор текущей строки (численное значение, согласно описанию в синтаксис-помощнике);
- в динамическом списке, когда источник и основная таблица есть справочник, метод ТекущаяСтрока() возвращает ссылку этого справочника, к которому не применим метод ПолучитьИдентификатор().
Решение проблемы:
Оказывается в метод Развернуть() в данном случае можно передавать эту ссылку, т.к. источник справочник, в котором нет дублей, следовательно система однозначно идентифицирует данную строку и сможет ее развернуть или свернуть. Аналогично работает и метод Развернут().
тд = Элементы . Дерево . ТекущиеДанные ;
Если Не тд = Неопределено Тогда
Если Элементы . Дерево . Развернут ( Элементы . Дерево . ТекущаяСтрока ) = Ложь Тогда
Элементы . Дерево . Развернуть ( Элементы . Дерево . ТекущаяСтрока , Ложь ) ;
КонецЕсли ;
КонецЕсли ;
Для удобства пользователя добавим, авто раскрытие/сокрытие при выборе(двойном клике, по уже активной строке):
Процедура ДеревоВыбор ( Элемент , ВыбраннаяСтрока , Поле , СтандартнаяОбработка )
ТС = Элементы . Дерево . ТекущаяСтрока ;
Если Элементы . Дерево . Развернут ( ТС ) = Истина Тогда
Элементы . Дерево . Свернуть ( ТС ) ;
Иначе
Элементы . Дерево . Развернуть ( ТС , Ложь ) ;
КонецЕсли ;
Данная статья также применима к плану счетов, планам видов характеристик и расчетов (которые имеют иерархическую структуру).
Газетные объявления содержат больше правды о том, что происходит в стране, чем газетные передовицы.
— Г. Бичер
Дабы избежать комментариев типа "тоже мне открытие!", оговорюсь сразу: статья рассчитана на неискушённых СКД-разработчиков, тем кто это и так знает не обязательно высказывать своё "фи!", поймите, то что очевидно для вас - не всегда бывает очевидно остальным.
Для наглядного представления реализации части трюков я сделал небольшие заготовки в виде внешних схем СКД. Описание трюков и скриншоты постарался делать так, чтобы суть и техника реализации трюка были понятны без необходимости скачивания схем. Для кого-то этого будет вполне достаточно, но если что-то непонятно, то всегда можно скачать соответствующую схему и посмотреть непосредственно реализацию.
Трюк №1. Многоликость правого значения.
Итак, для разогрева начнём с чего-нибудь попроще. В таких механизмах СКД, как "Отбор" или "Условное форматирование" вы наверняка сталкивались с колонками "Поле" (или "Левое значение") и "Значение" (или "Правое значение"). Профессионалы, наверняка знают этот трюк, но начинающим не всегда легко догадаться, что поле компоновки данных можно использовать как слева, так и справа (т.е. сравнивать не только заданные фиксированные значения, но и другие поля СКД в пределах одной строки). Для этого достаточно в поле правого значения зайти в режим редактирования, нажать кнопку очистки значения ("кретик"), затем нажать появившуюся кнопку выбора типа (буква "Т") и выбрать тип "Поле компоновки данных".
Пример.
В качестве примера я не стал изобретать велосипед, а взял самую обычную оборотно-сальдовую ведомость по счету 60 из демо-версии 1С:Бухгалтерии (я использую ред. 2.0.). Кто не знает, начиная с редакции 2.0 этот отчёт сделан на базе СКД.
Итак, зададим прямо в ней отбор для строк с условием "БУ Дт (оборот)" Равно "БУ Кт (оборот)", а также применим к отчёту условное оформление, подсветив жёлтым цветом ячейки строк, где "БУ Кт (кон. сальдо)" Больше "БУ Кт (оборот)". Если кто не знает, как включить панель "Оформление" - найдите кнопку "Параметры панели настроек" справа от надписи "Панель настроек".
Конечный результат должен получиться примерно таким:
Трюк №2. Отбор на группировках.
Все знают, что такое Отбор в СКД, но не все знают, что его можно применять не только для отчета в целом, но и на отдельных группировках строк и колонок. Прикладных задач для задействования такого средства много. Например, условная детализация (ограничение для каких группировок верхнего уровня выводить детализацию, а для каких нет), или вариативная детализация (для разных значений группировок верхнего уровня выводить разные расшифровки). На одном из проектов УПП, к примеру, пришлось делать форму калькуляции себестоимости с фиксированной структурой (отдельный справочник) и для разных статей калькуляции выводить расшифровки или по статьям затрат, или по конкретным затратам или не выводить ничего. Благодаря этому трюку не пришлось отказываться от СКД при разработке отчёта.
Пример.
Цель примера: отобразить ОСВ, в которой для взаиморасчетных счетов (60,62,76) показать расшифровку по контрагентам, а для затратных (20,23,25,26) - по статьям затрат.
Сама СКД реализована в виде набора данных, где используется запрос к виртуальной таблице остатков и оборотов регистра бухгалтерии "Хозрасчетный".
Размещаем вложенные группировки "Организация" и "Счет". В группировке "Счет" параллельно размещаем 2 группировки "Субконто1" и "Субконто2", для которых задаем соответствующие отборы.
Иллюстрацию настройки привожу в скриншоте:
Если в основных настройках отчёта на закладке "Другие настройки" вы не отключали вывод отборов, то это обязательно нужно будет сделать в "других настройках" наших группировок "Субконто1" и "Субконто2"
Трюк №3. Шапка-невидимка
Следующий трюк можно представить, как продолжение предыдущего. Если вы обратили внимание, в получившемся отчёте несмотря на то, что фактически у нас выводится только одно субконто, в шапку попадают оба (и "Субконто1" и "Субконто2"). К сожалению разработчики СКД не предусмотрели возможность регулирования видимостью шапки или использования какого-нибудь служебного символа, при установке которого в качестве заголовка, шапка поля бы не формировалась. Но, как вы уже, наверное, догадались есть трюк, который в какой-то степени поможет обойти данное ограничение.
При разработке схемы в предопределённом макете оформления добавьте макет группировки, с определением по имени группировки "Невидимка" так, как показано на скриншоте. Обратите внимание, что поле "Область" должно остаться пустым!
А затем задайте для группировки "Субконто2" имя "Невидимка":
И вуаля. шапка группировки "Субконто2" исчезает, а отчёт становится вот таким:
Спросите, почему макет оформления задаётся через имя, а не через указание конкретного поля группировки? Просто так получается более универсальное решение и впоследствии это имя группировки можно задать в вариантах отчёта на любой группировке, а вот менять предопределённый макет в вариантах уже не получится.
Да, есть ещё один ньюанс этого трюка: учитывайте, что "шапка-невидимка" накрывает не только эту группировку, но и все нижестоящие! Т.е. если вы назначите имя "Невидимка" группировке "Субконто1", то в шапке не будет видно ни "Субконто1", ни "Субконто2"!
Трюк №4. Называй меня как хочешь
Большинство разработчиков СКД знают, как можно задать заголовок поля запроса. На закладке СКД "Наборы данных", достаточно поставить галочку отмены автозаголовка и внести в поле "Заголовок" необходимый текст. Минус состоит в том, что в пользовательском режиме, этот способ недоступен, а переименовать заголовок хочется не прибегая к помощи конфигуратора. Так вот в настройках вариантов отчёта есть не только способ переименовать заголовки полей, но и "накрыть" их группировочной "шапкой". Для этого на закладке "Выбранные поля" необходимо выделить нужные поля и нажать правую кнопку мыши. Как видно на скриншоте для полей доступны опции "Установить заголовок" и "Сгруппировать поля".
Обратите внимание, что для полей группировок установку заголовка необходимо делать также именно через закладку "Выбранные поля", а не через контекстное меню "Установить имя" в верхней (структурной) части настройки варианта!
После всех настроек вариант отчёта выглядит вот так:
P.S.
Небольшая подсказка для тех, кто будет качать схему. Схема - одна, но все трюки выполнены в виде отдельных вариантов настроек отчёта этой схемы:
Заполняя форму ввода, мы работаем со связанными данными. Так, выбирая договор контрагента, мы ожидаем увидеть в форме выбора список договоров конкретного контрагента. Пользуясь текстовым поиском в поле реквизита формы, мы также должны увидеть список, удовлетворяющий как критериям введенного поиска, так и ограничениям связей. Так, введя часть номера договора, мы ожидаем увидеть список договоров конкретного контрагента, элементы которого содержат в номере набранный образец поиска. Аналогично система должна контролировать уже введенное значение в поле реквизита формы: значение должно удовлетворять ограничениям связей.
СВЯЗИ ПАРАМЕТРОВ ВЫБОРА
Платформа 1С позволяет описывать связи параметров выбора. По этим связям форма выбора автоматически настраивает фиксированные настройки отбора. Пользователь в форме выбора получает список элементов, соответствующих наложенным ограничениям связей. Аналогично платформа обрабатывает отбор элементов при формировании списка выбора. Когда пользователь вводит в реквизит формы текстовый образец строки поиска, платформа выполняет поиск элементов, соответствующих введенному значению по полям поиска, а также по условиям отбора, соответствующих связям параметров выбора.
Описанное поведение системы вполне нас могло устроить. Однако если, например, нужно настроить отбор по полю реквизита через точку, то такое мы сделать стандартно не сможем. Так же, если ограничение подразумевает использование критериев отбора через поля дополнительных таблиц, соединенных с основной таблицей выбираемого типа, то такой вариант также не предусмотрен платформой. И последнее, в платформе нет средств проверки выбранного значения на соответствие связям параметров выбора.
Однако, об этом мало кто знает, в качестве параметра выбора можно установить фиксированный массив, и тогда отбор будет не на равенство, а на вхождение значения поля основной таблицы в список значений установленного массива. И это полезно знать в рамках представленного решения, чтобы не реализовывать то, что и так поддерживается платформой.
Поясню на конкретных примерах. Представим себе форму, в которой есть два реквизита типа Контрагент. Скажем нужно указать первого контрагента, а потом выбрать второго. Однако второго контрагента можно выбрать только из той же группы контрагентов, в которой находится первый. Здесь условие связи параметров выбора могло бы быть таким: Отбор.Родитель = Контрагент.Родитель. Однако правое выражение через точку не поддерживается платформой и потому такое условие связи ввести нельзя.
Для второго примера представим себе форму, в которой в шапке есть реквизит типа Договор, а в табличной части - реквизит Статья. При этом выбор статей ограничен списком из регистра соответствия статей договору. Такое условие связей могло бы выглядеть так: Отбор.Ссылка = РС.Статья И РС.Договор = ДоговорКонтрагента. Однако в этом случае в условии задействована дополнительная таблица и такое условие также задать стандартно нельзя.
Предлагаемое решение как раз снимает указанные ограничения и позволяет использовать связи параметров как с реквизитами основной таблицы, так и с реквизитами связанных таблиц. Данное решение распространяется на все обозначенные сценарии ввода значения реквизита формы:
- ввод через форму выбора;
- ввод из списка выбора;
- определение однозначного значения выбора (предсказание выбора);
- проверка соответствия значения ограничениям по связям параметров выбора.
ПАРАМЕТРЫ ВЫБОРА
При вызове формы выбора или при подборе из списка платформа передает параметры, определенные по связям. Используя переданные параметры можно сформировать свой собственный запрос к данным и подменить выборку данных. Это нам необходимо для того, чтобы обойти ограничения описания условий связей. Перед рассмотрением указанного способа получения выборки давайте ознакомимся с существующими ограничениями платформы при описании связей.
Платформа накладывает следующие ограничения на создание выражений условий связей параметров. Имя параметра должно удовлетворять условиям написания имен (не содержать пробелов, начинаться может с буквы или символа подчеркивание); в имени можно использовать только одну точку или не использовать точку вообще. Значение параметра должно быть значением реквизита формы без использования подчиненных реквизитов, однако можно указать реквизит табличной части в специальном формате через элементы формы: Элементы.Список.ТекущиеДанные.ИмяРеквизита.
ОБХОД ОГРАНИЧЕНИЙ ПАРАМЕТРОВ ВЫБОРА
Практика
На практике мне попадались следующие решения:
- Передача в параметры формы выбора подготовленного списка ссылок для выбираемого типа данных
- Использование специализированной формы выбора с предопределенным запросом динамического списка
- Выбор из подготовленного списка значений
Недостатками этих решений являются:
- Не универсальность (необходимо разрабатывать специализированные формы выбора)
- Невозможность переиспользования данного подхода для формирования списка выбора
- Невозможность переиспользования для проверки введенного значения
Решение
В рамках наложенных ограничений платформы, недостающие параметры можно передать косвенно через указание реквизита формы. Так, если по приведенному примеру выше, нам нужно указать связь по родителю реквизита Контрагент, то условие связи параметров может быть таким: Отбор.КонтрагентРодителя = Контрагент. Тогда в форму выбора или же в предопределенную процедуру обработки выбора будет передан параметр с именем КонтрагентРодителя и значением реквизита формы Контрагент. Далее нам достаточно отработать условие по этому параметру, а именно использовать этот параметр для получения значения через точку Контрагент.Родитель и уже это, полученное косвенно, значение параметра использовать для установки необходимого отбора по родителю.
Аналогично для второго примера условие связи будет: Отбор.Договор = Договор. Несмотря на то, что условие накладывается на справочник Статьи, в котором отсутствует поле Договор, такое условие в рамках платформы вполне допустимо использовать. В этом случае в форму выбора будет передан параметр Договор со значением из реквизита формы Договор. Далее нам необходимо построить запрос через соединение основной таблицы Статьи с таблицей РегистрСведений.СтатьиДоговора и уже на поле регистра сведений наложить условие отбора по переданному значению договора.
Таким образом можно обойти ограничения платформы и передать в форму выбора необходимые параметры. Далее необходимо исходя из переданных параметров построить текст запроса. Полученный текст запроса можно использовать как в форме выбора, так и в предопределенной процедуре получения данных выбора для формирования списка.
ПОДСИСТЕМА РАБОТА С ДАННЫМИ ВЫБОРА
Рисунок 1. Диаграмма последовательности
Предлагаемая подсистема реализует интерфейс для работы следующих сценариев:
- Быстрый выбор из списка - поддерживается поиск по началу или по вхождению по полям поиска, реализована подсветка найденных фрагментов вхождения текста
- Выбор из формы выбора - поддерживается нестандартная реализация отборов с возможностью вывода иерархии (для иерархических справочников)
Подключение к подсистеме производится через вставку вызова в форме выбора и добавление предопределенной процедуры менеджера объекта ОбработкаПолученияДанныхВыбора.
Обработка параметров, функция ПолучитьТекстЗапроса
В предлагаемое решение строится вокруг реализации функции ПолучитьТекстЗапроса. Реализация данной функции не является обязательной и нужна только для тех типов данных, выборка которых ограничивается не только по реквизитам основной таблицы.
Основное назначение функции - в получении текста запроса по переданным параметрам. В отличии от стандартного поведения платформы, когда в форму выбора передаются параметры, эта функция не имеет ограничений: в ней можно реализовать любые условия выбора. Однако и здесь есть ограничение платформы: результирующий запрос не должен содержать объединений ни в одном из пакетов запроса. Это ограничение накладывается реализацией динамического списка, в котором на текущий момент объединения не поддерживаются (однако объединение можно использовать во вложенном запросе!).
В следующем листинге демонстрируется пример-заготовка реализации такой функции. Данная реализация основана на использовании объектной модели запроса. Работа с объектной моделью осуществляется с использованием подсистемы "Работа со схемой запроса". С шаблонами построения текста запроса при использовании подсистемы можно подробнее ознакомиться в одноименной статье.
Листинг 1. Общая структура функции ПолучитьТекстЗапроса на примере справочника _ДемоНоменклатура
Динамический список формы выбора
После того, как мы разобрались с механизмом получения текста запроса по переданным параметрам, давайте рассмотрим, как его использовать для формирования динамического списка формы выбора.
Подготовка динамического списка может быть осуществлена в предопределенной процедуре модуля формы: ПриСозданииНаСервере. В этой процедуре доступны параметры выбора, которые необходимо передать в функцию формирования текста запроса. Полученный текст запроса необходимо установить в динамическом списке. Для того, чтобы динамический список работал, необходимо также установить параметры отбора динамического списка (это те параметры, которые нельзя установить в условиях отбора данных основной таблицы, но можно использовать в тексте запроса).
Для работа подсистемы необходимо настроить динамический список формы выбора: установить произвольный запрос и изменить псевдоним основной таблицы на имя "Источник".
Разберемся подробнее с параметрами отбора и установкой отбора в динамическом списке. Стандартным образом отбор в динамическом списке платформа устанавливает по параметрам структуры переданного отбора. В нашем случае в этой структуре могут быть как поля основной таблицы, так и параметры, используемые для получения значения отбора косвенно. Параметры второй категории необходимо установить в процедуре ПриСозданииНаСервере и они же должны быть указаны в тексте запроса, а параметры первой категории оставить в структуре отбора. Тогда платформа получит в качестве отбора поля основной таблицы и стандартным образом настроит элементы фиксированного отбора по переданным значениям после открытия формы выбора.
Таким образом, для работы формы выбора с динамическим списком необходимо разделить переданные параметры на отбор по реквизитам основной таблицы и параметры запроса. Первые должны остаться и будут стандартным образом обработаны системой, а вторые необходимо использовать в тексте запроса динамического списка и установить программно в параметрах динамического списка.
Листинг 2. Демонстрация разделения параметров в функции ПолучитьТекстЗапроса
Листинг 3. Подключение формы выбора к подсистеме
Примечание: подключаемая форма выбора должна содержать произвольный текст запроса основной таблицы, при этом псевдоним основной таблицы должен быть предопределенным «Источник». Этот же псевдоним используется в подсистеме для построения текста запроса путем добавления условия и соединений.
Список данных выбора
Рисунок 2. Список выбора
Механизм получения списка данных выбора аналогичен описанному для динамического списка формы выбора.
Как и для формы выбора здесь при вызове предопределенной процедуры ОбработкаДанныхВыбора будут переданы параметры, в том числе и параметры связей выбора. Далее необходимо получить текст запроса и установить значения переданных параметров в запрос программно. К полученному запросу необходимо применить отбор по условию вхождения переданного образца в строке поиска в значения по полям поиска.
После выполнения полученного запроса в процедуре формируется список, который используется платформой для вывода на экран списка выбора.
Листинг 4. Подключение процедуры к подсистеме
Проверка на соответствие условиям параметров выбора. Заполнение по-умолчанию.
Теперь, когда мы умеем формировать текст запроса по условиям связей, мы можем также проверить текущее значение реквизита на соответствие условиям связей. Это может быть полезным, когда меняются связи (топология), либо меняются значения связей, либо производится выбор значения из истории списка.
Если в выборке по условиям связей мы получим единственное значение, то его можно использовать для заполнения реквизита по-умолчанию. В этом случае пользователя не обязательно заставлять сделать выбор, когда выбора то и нет.
Листинг 5. Проверка соответствия переменной СсылкаНаЗначение переданным параметрам выбора из структуры Параметры
СТЕНД "РАБОТА С ДАННЫМИ ВЫБОРА"
Рисунок 3. Форма обработки стенда
Для демонстрации работы подсистемы выбран справочник _ДемоНоменклатура из демо-конфигурации БСП. С помощью расширения конфигурации в справочнике доработан менеджер объекта и форма выбора. В модуль менеджера добавлена функция ПолучитьТекстЗапроса и предопределенная процедура ОбработкаДанныхВыбора. В форме выбора добавлен вызов процедуры ЗаполнитьТекстЗапросаДинамическогоСписка.
В функции ПолучитьТекстЗапроса реализована обработка дополнительных параметров:
- Организация и Контрагент - формируется список номенклатуры, которая использовалась в документах реализации
- Договор контрагента - формируется список номенклатуры, определенный в регистре сведений НоменклатураДоговора
- Дополнительные реквизиты - отбор по реквизитам из табличной части номенклатуры
- Дополнительные свойства - отбор по свойствам, определенным в регистре сведений СвойстваОбъектов
В процедуре используются приемы по формированию текста запроса в объектной модели с использованием подсистемы РаботаСоСхемойЗапроса. Более подробно читайте здесь.
Читайте также: