ЧПУ в сайтах с фасетным методом классификации

[skrpnk]

В общем, есть два метода классификации: иерархический и фасетный. С первым всё вроде бы понятно: Главная/О компании/История (/about/history). И с ЧПУ нет проблем и «хлебные крошки» можно смело применять.

А вот со вторым проблемы, так как параметров у одной страницы много и основной выделить бывает сложно. Для примера возьму каталог портативной

Comments

[b00ter]

> Не по-человечески, и не эстетично.

А надо шашечки или ехать? В принципе, можно разрешить относительно функции, задаваемой посетителем:
/viewbyvendor/cellphones/nokia/3310
/searchbyprice/cellphones/maxprice/10000

[skrpnk]

Да, как вариант.

Но хотелось бы, чтобы можно было просто в урле ввести бренд и модель и получить сразу то, что нужно, не заходя на сайт. Можно это организовать алиасами, а можно просто на это забить.

Проблема №2 - если поиск производится по нескольким параметрам?

[b00ter]

Если мы вводим в URL функционал, то количество параметров и их формат мы уже можем зафиксировать. Например,

/searchbyprice/cellphones/maxprice/10000
/searchbypriceandvendor/cellphones/maxprice/10000/minprice/0/vendor/nokia

Разумеется, можно ограничится неким общим сценарием, а опущеные параметры считать по умолчанию.
В любом случае лучше использовать именно пару "название_переменной/значение", чем задавать параметры позиционно. При этом можно еше, для отсутствия коллизий ввести для параметров префикс - мелочь, а приятно:

/search/cellphones/p-maxprice/10000/p-minprice/0/p-vendor/nokia

Преобразовывать можно как при помощи mod_rewrite, так и в лоб языком программирования.

[skrpnk]

Это не панацея, так как:
1. сценарии searchbyprice, searchbypriceandvendor, а дальше? searchbypriceandvendorandweightandcolordepth? При увеличении числа параметров урл станет монстроподобным
2. проблема зеркал
3. отсутствие логики дерева

По, моему, нужно рыть в другом направлении, например, в человеко-программном поиске. Типа /search/сотовый телефон samsung дешевле 500$

Веб 3.0, приди!

[slovinsky]

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

если хотите сохранять путь пользователя - то это уже другая тема, она хлебными крошками не называется, да и у юзера есть навигация браузерная туда-обратно, которой можно помочь кнопкой "вернуться назад" с JS хисторибек

а реализовать в URL фассеты можно - закрепить постоянные места за классификаторами, а не выбранные значения обозначать как "0":
телефоны / GSM / от $200 до $300 / Nokia
все телефоны: phones/gsm/ (воспринимается как phones/gsm/0/0/)
все сотики Nokia: phones/gsm/0/nokia/

и т.д.

[skrpnk]

Крошки у фасета не нужны, это да. А при твоём варианте получается, что
телефоны / GSM / от $200 до $300 / Nokia

то же самое, что и
телефоны / GSM / Nokia / от $200 до $300

Нехорошо это, зеркала. Да и принцип иерархии ломается.

[slovinsky]

Нет, я же говорю - закрепить порядок
На третей позиции - всегда диапазон цены, т.е. нельзя запросить страницу:
phones/gsm/nokia/200/
правильно только
phones/gsm/200/nokia/

при этом на станице не выбранные параметры просто не показываются:
путь: phones/gsm/0/nokia/
крошки: телефоны / GSM / Nokia

[skrpnk]

Страшно представить вот такой урл:
phones/gsm/0/nokia/0/0/0/0/0/0/0/0/0/0/0/32/0/0/yes/

И тем не менее, следует отметить, что решение для старой модели веба очень даже рабочее. Но логики в нём нет, параметры не наследуются, они равнозначны.

[stialen]

1. Чем иерархия отличается от дерева?
2. Есть пять видов классификации. А методов - два: иерархический и фасетный.

[skrpnk]

1. ОписАлся. Исправил.
2. Ага, я про методы.

[stialen]

Попробуй использовать фолксономию