При работе с управляемыми формами в платформе «1С:Предприятие 8.3» разработчики часто сталкиваются с необходимостью оптимизировать интерфейс. Один из частых сценариев — скрыть второстепенные колонки динамического списка, чтобы не перегружать экран пользователя. Однако возникает проблема: стандартная строка поиска, расположенная над таблицей, по умолчанию ищет информацию только по тем колонкам, которые физически отображаются на форме. Если колонка скрыта (ее видимость установлена в значение Ложь), стандартный поиск по ней работать перестанет.
В этой статье мы подробно разберем, почему так происходит, рассмотрим два практических способа решения этой задачи (через условное оформление и с помощью программного отбора), а также уделим особое внимание вопросам производительности базы данных при работе с такими механизмами.
Поведение платформы «1С:Предприятие» при работе с динамическими списками жестко завязано на оптимизацию клиент-серверного взаимодействия и запросов к СУБД:
Видимость = Ложь или если пользователь сам отключил ее отображение через настройки), платформа физически исключает это поле из списка выбираемых в SQL-запросе.SELECT SQL-запроса). Однако для стандартного поиска этого всё равно недостаточно, так как элемент управления на форме остается невидимым, и механизм поиска его игнорирует.---
Этот изящный трюк был предложен участниками форума и позволяет «обмануть» логику платформы, заставив её считать скрытое поле условно отображаемым.
Разберем по шагам, как настроить этот механизм в конфигураторе:
ПутьКДанным не привязано к элементу. Нам не нужно выводить его стандартным способом.Видимость и установите его в значение Ложь.Почему этот способ работает? При такой настройке для платформы колонка считается «активной» в структуре таблицы формы, но визуально скрывается на этапе отрисовки интерфейса с помощью механизма условного оформления. В результате генератор стандартного поиска платформы продолжает включать данное поле в область действия поисковых запросов, и пользователи могут находить строки по скрытому значению.
---
Использование условного оформления — отличный быстрый вариант, но он имеет свои минусы. Другим разработчикам, которые будут поддерживать конфигурацию после вас, может быть сложно сразу понять, почему поиск работает по скрытому полю. Более профессиональным и прозрачным решением считается создание собственной строки поиска с программным наложением отбора.
Рассмотрим по шагам, как реализовать этот подход:
СтрокаПоиска и типом данных Строка.КнопкаОчистки = Истина.ПриИзменении для созданного поля ввода СтрокаПоиска.Проанализируем программный код, который необходимо разместить в модуле формы для реализации поиска:
&НаКлиенте
Процедура СтрокаПоискаПриИзменении(Элемент)
// Определяем имя скрытого реквизита, по которому будем искать
ИмяПоля = "ИмяСкрытогоРеквизита";
ПолеКомпоновки = Новый ПолеКомпоновкиДанных(ИмяПоля);
// Шаг 1. Очищаем предыдущие отборы по этому полю, чтобы они не дублировались
МассивДляУдаления = Новый Массив;
Для Каждого ЭлементОтбора Из Список.Отбор.Элементы Цикл
Если ТипЗв(ЭлементОтбора) = Тип("ЭлементОтбораКомпоновкиДанных")
И ЭлементОтбора.ЛевоеЗначение = ПолеКомпоновки Тогда
МассивДляУдаления.Добавить(ЭлементОтбора);
КонецЕсли;
КонецЦикла;
// Удаляем найденные старые элементы отбора
Для Каждого ЭлементУдаления Из МассивДляУдаления Цикл
Список.Отбор.Элементы.Удалить(ЭлементУдаления);
КонецЦикла;
// Шаг 2. Если пользователь ввел поисковый запрос, накладываем новый отбор
Если ЗначениеЗаполнено(СтрокаПоиска) Тогда
НовыйОтбор = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
НовыйОтбор.ЛевоеЗначение = ПолеКомпоновки;
НовыйОтбор.ВидСравнения = ВидСравненияКомпоновкиДанных.Содержит;
НовыйОтбор.ПравоеЗначение = СокрЛП(СтрокаПоиска);
НовыйОтбор.Использование = Истина;
КонецЕсли;
КонецПроцедуры
Преимущества программного метода:
---
Любой поиск по динамическим спискам (особенно по скрытым полям) может серьезно нагрузить сервер СУБД и замедлить работу пользователей. Выясним основные причины просадки производительности и способы борьбы с ними:
Содержит транслируется платформой в SQL-конструкцию LIKE '%Значение%'. База данных не может эффективно использовать обычные индексы при поиске подстроки, начинающейся с процента. Если скрытый реквизит содержит длинные строки или неограниченную длину, СУБД будет перебирать всю таблицу целиком.
---
Если в настройках вашего динамического списка в конфигураторе заполнено свойство «Основная таблица», платформа задействует оптимизированные механизмы работы со списками, включая встроенный Полнотекстовый поиск (ППД).
Если для вашего скрытого реквизита в свойствах объекта метаданных (например, реквизита справочника) установлено свойство Полнотекстовый поиск -> Использовать, то стандартная поисковая строка платформы сможет успешно находить элементы по этому скрытому реквизиту даже без использования «хака» с условным оформлением и без флага «Использовать всегда». Однако помните, что этот механизм будет стабильно работать только в том случае, если в вашей базе данных настроено регулярное и своевременное обновление индекса полнотекстового поиска.