Сообщений в теме: 12

[andrey.kalinin]

Помогите с решением проблемы многоуровневого фильтра.

Есть таблица Покупки и подчиненная таблица Товары.
В таблице Товары есть поля:
- Торговая марка
- Тип товара
- Наполнение

Товар продается под двумя торговыми марками. (ТМ1 и ТМ2).
Есть некоторое кол-во типов товара (булочка, круасан, пирожок). При этом у разных торговых марок есть типы товара с одинаковым названием.
Так же есть несколько вариантов наполнения.(варенье, заварной крем, шоколад....)

При добавлении новой строки, в таблицу Покупки из подчиненной таблицы Товары, при помощи типа поля "связь" выбирается:
- Торговая марка (ТМ1 или ТМ2)
- Тип товара (фильтр по полю Торговая марка)
- Наполнение (Фильтр по полю Тип товара)

Напрмер запись в таблице Товары:
ТМ1 - булочка - вишневое варенье
ТМ1 - круасан - шоколад
.....
ТМ2 - булочка - вишневое варенье

Добавляем новую строку в таблицу Покупки:
- поле Торговая марка - варианты выбора:ТМ1/ТМ2 (выбираем "ТМ1")
- поле Тип товара - вырианты выбора: булочка/круасан (выбираем "булочка")
- поле Наполнение - варианты выбора: вишневое варенье/вишневое варенье

Подскажите пожалуйста как создать фильтр, который учитывал бы несколько уровней выбора (ранее выбранную Торговую марку и Тип товара)?

Спасибо!

[CbCoder]

Не совсем понял, в чем именно проблема, и что имеется ввиду под многоуровневым фильтром? Если речь о нескольких уровнях фильтров по полю, то судя по вашему подробному описанию, вы их уже благополучно настроили и они у вас работают, не так? Или же речь идет о неких многоуровневых фильтрах в верхнем меню (там где Категории и Таблицы)?

[andrey.kalinin]

Добрый день!
Речь идет о нескольких уровнях фильторов по полю.
Из настроенных мной фильтров выборка получается не совсем корректной.

При рассматривании примера Категория/подкатегория/товар и установке фильтров:
подкатегория - фильтр по полю Категория
товар - фильтр по полу подкатегория
То возникает следующая ситуация: Если в разных категориях есть одинаковые подкатегории, то при выборе товара выборка происходит среди подкатегорий с одинаковым названием у разных категорий.

Поскажите пожалуйста пример кода для создани собcтвенного фильтра со следующей логикой, для таблицы "Покупки":
При добавлении строки, предложить на выбор значения поля "Товар" из таблицы "Продукты", у которых поле "Категория" = полю "Категория" в добавляемой строке + поле "Подкатегория" = полю "Подкатегория" в добавляемой строке.

Спасибо

[lodion]

Тема старовата и не знаю, было ли решено. Но! У меня точно такая же проблема. Есть идеи, что может быть не так? Почему поиск не многоуровневый, а два одноуровневых?

[CbCoder]

Если все поля в цепочке - поля связи с одной таблицей, и если каждое последующее поле фильтруется вышестоящим, то всё "так". Если же тем не менее не работает - скорее всего баг, отправьте заявку в ТП.

[lodion]

К моему большому сожалению, все должно быть "так". Но из ТП мне ответили вот что:

Цитата

Здравствуйте! Фильтрация по третьему полю изначально не работала. И это не получится изменить отдельно в конфигурации. Данный функционал реализуется только в движке программы. Но по скольку это вызывает нагрузку на сервер многоуровневая фильтрация по 3 полю невозможна.

Как вариант решения можно было бы оптимизировать след.образом.
Например:
1. Есть 3 таблицы Контрагент, Тип, и Наименование.
2. У т. Контрагенты подтаблица Тип
4. У т. Тип - подтаблица материалы
3. в т. Приход на Склад: поле Контрагент связь с т. Контрагенты; поле Тип связь с т. Тип, фильтр По полю Тип; поле Наименование - связь с т. Наименование, фильтр по полю Наименование.Тип.

То есть оптимизировать связь полей используя подчинение таблиц.
К сожалению другого варианта нет

А очень жаль.

[CbCoder]

Ну значит действительно было отключено, по причине чрезмерной нагрузки. Думаю, вряд ли вас бы устроило формальное разрешение, которое привело бы к тотальному зависанию страниц. Но тем не менее решение то есть, вам его предложили, чем оно вас не устраивает? Грубо говоря, один справочник "Страна-Регион-Город" делится на 3 таблицы, со связями между ними, в итоге вы все равно получаете тоже самое, но более оптимальное по структуре и быстродействию. Для пользователя, выбирающего значения в итоговой форме, разницы не будет никакой.

[lodion]

Меня не устраивает тем, что при переделывании полей, данные в них слетят.
Если будет возможность просто сделайте реализацию INNER JOIN.
А для одной таблицы там даже без join будет... В общем, Вы меня поняли.
В любом случае, буду рад, если рассмотрите это предложение.

[lodion]

Уважаемый CbCoder, не могли бы Вы прояснить для меня такой момент: в базе данных, при установке фильтрации по полю для поля с типом "связь", третьим пунктом type_value устанавливается id этого поля с отрицательным значением. А при установке фильтра "с остатком" устанавливается значение 166. Прошу Вас, проясните для меня, что же значит этот type_value[2]. И по какой логике устанавливается

Добавлено:
Даже не так. По какой логике он анализируется! Это важнее.

Добавлено2: есть предположение, что с минусом - поле, с плюсом - фильтр... Надеюсь, что это может получить развитие...
Можно ли задать еще что-то?.. Вычисление, например. Или в фильтр передать какие-то значение из $line?

Сообщение отредактировал lodion: 21 Май 2015 - 10:20

[CbCoder]

А вам с какой целью это надо? Мы как правило не даем комментариев по внутренней структуре хранения служебных данных, т.к. это не входит в изначально предусмотренный механизм стороннего расширения программы. Плюс, 1) это все может смениться в любой момент и в любой ревизии, 2) мы сами порой плохо помним что там было "неверчено", и это требует времени на разбор. Никакой документации на этот счет нет, по причинам изложенным выше. В конце концов, вы же не можете менять код движка программы (он закрыт), тоже самое и со служебными данными в БД или .tpl файлами, хотя формально они и открыты.

[lodion]

Это может весомо расширить функционал программы...
К примеру. через интерфейс нельзя сделать правило для группы пользователей и по условию поля. А в БД нужно только поменять user['id'] на user['group_id'] - и все!
А вычисления в фильтре? Это клад! Это же возможность подтягивать значения из родительских таблиц, проверять пользователя и т.д.
А правила? Это только кажется, что они где-то там не работают. Я нашел способ регулировать возможность добавления в подтаблицы. И он не криминальный, это УЖЕ СУЩЕСТВУЮЩИЙ функционал КБ.
Таких возможностей, я уверен, - море.

Да, я понимаю, что все эти замечательные возможности могут накрыться в любой момент. Но я придумаю еще что-нибудь. В конце концов, вряд ли разработка функционала уйдет в обрезание возможностей. КБ позволяет даже сейчас намного больше, чем позволяет интерфейс.
Пожалуйста, если Вас не затруднит, напишите мне ответ каким-либо образом (личные сообщения для меня недоступны).
Да, возможно, влезание без понимания структуры все сломает, но я буду осторожен. В PHP и SQL разбираюсь.
Если есть возможность передать в фильтр значение перед его применением для поля, это было бы идеально!

[CbCoder]

lodion (21 Май 2015 - 12:49) писал:

Пожалуйста, если Вас не затруднит, напишите мне ответ каким-либо образом (личные сообщения для меня недоступны).

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

lodion (21 Май 2015 - 12:49) писал:

Это может весомо расширить функционал программы...

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

[lodion]

Эх... ... Ну, будем ждать версии 3.0. Как маны небесной.