Дано:
Портал,
портал может фильтроваться реляцией или собственным фильтром
Глобальное поле для ввода данных.
Найти:
при вводе данных в глобальное поле, набор данных в портале динамически меняется согласно фильтру. Без необходимости нажимать дополнительные кнопки
Проблема: либо это все будет жутко тормозить, либо ввод данных сбивается (из-за тормозов), либо требуется Commit (то бишь выход из поля и возврат в него), короче, работает некрасиво.
Как сделать оптимально?
Видел такие решения:
при каждом нажатии символа содержимое поля передается параметром в скрипт PSOS (без ожидания), на сервере поиск обрабатывается, результат вставляется в хранимое поле, по которому организована реляция в портале. Пользователь вводит, портал асинхронно фильтруется. Красиво, но громоздко и все-таки PSOS, локально работать не будет.
Триггер в глобальном поле - рекурсивный, вызывает сам себя с задержкой в одну секунду командой Install On Timer (с флагом). При быстром вводе символов в глобальное поле он не успевает исполниться, получается серия команд Install, каждая последующая отменяет предыдущую. И лишь когда пользователь перестает стучать по клаве, срабатывает таймер, а в этом случае по флагу исполняется основная функция скрипта - происходит обновление портала.
Кто как красиво реализовывал? как сделать быстро? Как сделать без коммита и тормозов?
Давайте оптимизируем. Фильтр портала
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: Давайте оптимизируем. Фильтр портала
в первом варианте вам все равно нужен комит, иначе портал не обновится.
html-таблицу на веб-вьюеереКак сделать без коммита и тормозов?
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: Давайте оптимизируем. Фильтр портала
да, это тоже вариант, кстатиhtml-таблицу на веб-вьюеере
без коммита я бы поигрался настройкой фильтра через глобальную переменную, а не через поле. То есть, к примеру, данные из поля я записываю в глобальную переменную и затем обновляю портал, который чувствителен именно к глобальной переменной. Но мне этот способ кажется сложноватым
-
- Сообщения: 106
- Зарегистрирован: 21 сен 2017, 18:48
- Откуда: Минск
Re: Давайте оптимизируем. Фильтр портала
При работе с сервером: фильтр портала, насколько я понимаю, тянет сначала все данные для отображения портала т.е. по реляции (а это можте быть много записей) а потом скрывает при отображении те, что попадают под фильтр. Для больших список предпочтительнее фильтр через реляцию. Я пользуюсь описанным вами тригером в глобальном поле.
При этой технике более гибкий поиск у меня получался (например с исключениями или по отдельным полям), когда я использовал не фильтр портала, а обычный ListView и режим Find через скрипты в специальном окне (например CardView). Мне было удобно, что можно было в зависимости от количества найденных записей переходить на разные макеты (найдена одна запись- к карточке, найдено несколько - к списку, ничего не найдено - предложение ввести новую)
При этой технике более гибкий поиск у меня получался (например с исключениями или по отдельным полям), когда я использовал не фильтр портала, а обычный ListView и режим Find через скрипты в специальном окне (например CardView). Мне было удобно, что можно было в зависимости от количества найденных записей переходить на разные макеты (найдена одна запись- к карточке, найдено несколько - к списку, ничего не найдено - предложение ввести новую)
Re: Давайте оптимизируем. Фильтр портала
Кажется у Soliant было целое исследование, они сравнивали разные способы нахождения списка id записей, победитель не выявился, зависит и от количества записей вообще, и от того сколько записей находится. Если нашлось тысячи записей, то собрать "айдишки" в кучу тоже занимает время.