Пишу свой магазин. Нужен совет по организации фильтров. Вопрос, собственно, в том, как анализировать формирующиеся ссылки. Для примера описываю простую модель. Товар - мониторы. Фильтры (3 шт.) - по производителю, размеру диагонали и цвету. Соответственно, ссылка может иметь различный вид: sitename.ru/aser/22/black/ sitename.ru/white/17/samsung/ sitename.ru/19/nec/silver/ sitename.ru/23/silver/ sitename.ru/silver/ Такое построение я неоднократно видел на различных сайтах и оно мне нравится. Реализовать решил упрощенным способом - получать полный путь в виде строки (через ModeRewrite), а затем анализировать полученную строку. К примеру, при разборе получаем очередной фильтр в виде строки "black", определяем, что это одно из значений характеристики "цвет" (color), действуем выборку и т.д. Нюанс состоит в том, что при таком алгоритме значения фильтров не должны дублироваться в различных характеристиках. Т.е., например, если существует значение "white" в характеристиках цвета, то такое значение не должно присутствовать в остальных характеритиках. Существуют ли более тривиальные решения такого алгоритма?
Алгоритм может быть ровно таким, какие возможности по распознаванию у человеческого мозга. Делать такой ёбнутый адрес, в котором постоянно всё не на своих местах - это как шило в жопе, а толку ноль Фиксируй адресацию и не еби мозг. Если предположить, что есть строго типизированная структура Items с элементами: Код (Text): struct Items { int general; double price; char* brand; char* name; }; Есть уровень сложенности, назовем его L. Всего количество запросов к БД (без учета структуры) равно факториалу L (L!), в данном примере 4!=24 запроса к БД. Если учесть строгую типизацию, то вычитываем два элемента, которые займут всегда определенный столбец, т.е L-2, итого получаем вариацию из двух запросов. В случае выше зацепится можно только за цифры, в итоге - тоже два запроса из возможных 6. Это обычный вариант перебора, идиотизм. Если делать вычисление по множествам, в которых может быть пересечение, то это ещё больший капец.
Фиксировать каим образом? Строить адреса типа sitename.ru?color=white&diagonal=19 ?! Такой вариант не приемлем. Во-первых, он плохо индексируется поисковыми системами. Адрес типа sitename.ru/white/17/samsung/ будет гораздо информативнее. Во-вторых, по алгоритму, описанному мной, на сайте можно выстраивать цепочки feedback'ов (хлебных крошек), например: "Белый цвет -> Диагональ 17" -> Самсунг", и пользователь всегда может вернуться назад в соответствии с ОЧЕРЕДНОСТЬЮ выбора характеристик? которую он делал изначально.
alpinist777 Не надо путать просто ModRewrite с произвольным порядком передачи аргументов. Это в корне разные вещи
Apple Я понял, Вы говорите про фиксирование позиций как про фиксирование порядка передачи аргументов, т.е. их очередность, так? Что-то вроде, если аргумента 3, то на первом месте, например, марка, на втором диагональ, на третьем цвет. А если их 2 или 1? Заранее не определишь. Забивать значения-null типа sitename.ru/samsulg/all/all - уже некрасиво, а представьте, что аргументов 8 или больше Есть у меня еще один вариант. Дополнить значения параметры их названиями, например, так: sitename.ru/marka-samsung/diagonal-19/color-white/ Такой способ и для индексации может даже лучше, и анализировать просто в любом порядке передачи аргументов. Незначительный минус - слишком длинная строка при большом количестве аргументов.
Для удобства разбора можно использовать что-то вроде /color-white/brand-samsung/size-17/ Но на самом деле такие выборки делаются набором полей с параметрами, и хлебные крошки тут не нужны. То, что вы хотите сделать будет лишь путать людей и заставлять их делать лишние клики, тогда как они могут сразу сформировать весь фильтр и получить что нужно.
Блин, так бы сразу и сказал. А-то логика построения фильтров, я подумал, что ты собрался менять местами такие вещи как aser, white и пр. А если всего лишь количество аргументов, то тут всё просто. Сейчас отпишусь.
Разбирай адрес на основе количества вложенных элементов, динамически собирая запрос. Если тебе известен родитель, то тебе известны все его дети. У тебя иерархия сделана в виде Adjacency list или nested sets?
Apple, менять местами ТОЖЕ. т.е. значений может быть произвольное количество, и порядок следования в строке адреса может быть различным.
Apple, структура не иерархична. Фильтрами являются характеристики товара. Для мониторов, например, размер диагонали типичная характеристика, но цвет - характеристика универсальная для любого товара.
MiksIr, пример с мониторами я привел лишь в качестве примера. Отдельный модуль для "сразу сформировать весь фильтр и получить что нужно" конечно будет реализован. Однако такой модуль хорошо смотрится при продажах технических изделий (от компьютерных комплектующих до технических инструментов). В интернет-магазинах, посвященных шмоткам (бальные платья, женских трикотаж и т.п.) лучше реализовать красивый поэтапный фильтр с возможностью выбирать характеристики в любом порядке (бренды и коллекции, фасоны и цветовые решения, состав тканей и размеры вещей). У меня направление второго типа. 2 магазина существуют уже более года. Реализованы на базе WebAsysyt'a. К написанию своего скрипта сподвигдо желание расширить функциональные возможности для узкоспециализированной тематики.