mindguru сказал(а) 08 Ауг 2013 - 17:10:
Кстати (ну это уж совсем оффтопик, просто к слову пришлось). Как Вы решаете проблему хлебных крошек? Поясню. Категории Zoo на моём сайте броузятся отдельным скриптом, с него же переход потом уже непосредственно на итем. Так вот, чтобы после перехода в хлебных крошках осталось название категории, обязательно нужно в ссылке указать Itemid пункта меню. Это означает обязательное создание пунктов меню по количеству категорий, что далеко не всегда бывает удобно. Что Вы посоветуете в этом случае?
Ну это известная проблема (фича?) ZOO. Вот официальный срач по этому поводу 
Чтобы сделать нормально, а критерием нормальности я считаю вид: category_level_1_alias / category_level_2_alias / ... /item_alias , и не использовать сторонние компоненты, то есть только один путь - переписывать роутер под себя.
Метода простая. В роутере вы отслеживаете id категории айтема и начинаете из таблиц zoo_category_item и zoo_categories по полю parent "раскручивать" дерево категорий от текущего уровня вверх до корня. Каждый уровень - это 1 уточняющий наличие родительской категории SQL запрос. Если у вас 1 категория - 1 запрос, 2 категории - 2 запроса и т.д. Раскрутив категории в динамические массив, потом вы по сегментам можете "собрать" требуемый путь, чтобы было красиво. То же самое можно делать при помощи объектной модели ZOO , используя методы класса Item - getRelatedCategoryIds(), getPrimaryCategory(), getPrimaryCategoryId() и методов класса Category - hasChildren(), getParent(), getPathway().
У этого способа множество недостатков. Первый и самый важный: и при прямых запросах и при объектном программированни при количестве вложенности категорий более двух MySQL танцует ламбаду от навалившихся на него запросов на каждый генерящийся на странице линк. Если у вас 20 айтемов на странице категории 3ей вложенности - это +60 запросов. А если это 100 айтемов в табличном выводе с линками на "подробно"? Это уже 300. При высокой посещаемости проекта вам понадобится очень хороший сервер, да и то, не факт, что не будет космических лагов. Разработчикам сторонних роутеров пофиг - они продают коммерческое решение, не особо задумываясь о ресурсах пользователя, потому они акцентируют внимание на результат, а не на скорость работы продукта. Но смею вас заверить, приведенная мною методика с использованием SQL запросов - единственный путь получить требуемый результат, потому вы в любом случае получите нагрузку. Ну или надо линковать все категории и айтемы в меню, сохраняя иерархию. Думаю, что последний вариант для серьезного проекта не подходит.
Второй недостаток в том, что каждому айтему в ZOO вы можете присвоить несколько категорий. В этом случае вы получаете проблему множественности возможных путей.
Простой пример. Я начинающий сайтостроитель и не знаю что такое атрибуты товара, зато я научился делать категории и присваивать их в админке. Я продаю каски. Военные и строительные. Хаки и оранжевые. Я делаю категорию "По назначению" и в ней 2 подкатегории "Военные" и "Строительные", а потом еще делаю категорию "Цвет" и в ней 2 подкатегории "Хаки" и "Оранжевые". Товару "Строительная каска оранжевая" я присваиваю 2 категории - "По назначению/Строительная" и "Цвет/Оранжевые". Эта каска у нас отображается например в модуле ZOO Items. В данном случае линк на этот товар может иметь 2 абсолютно корректных пути - "По назначению/Строительная/Строительная каска оранжевая" и "Цвет/Оранжевые/Строительная каска оранжевая". Какой путь будет выбран - зависит от прописанного в роутере алгоритма: используется ли проверка множественности категорий, и если да, то какая именно запись принадлежности айтема к категории из zoo_category_item будет использована - та что, про назначение или та, что про цвета.
Думаю, что совокупность этих недостатков, в конченом итоге, и привела разработчиков ZOO именно к тому решению, которое мы видим в данный момент.
Иногда "продвинутые" SEF-помешанные клиенты все-таки настаивают, потому рождаются компромиссы. Пример с того же сайта
http://autokolesa.com.ua/tyres - имеем путь Главные / Шины (это из меню)
Далее кликаем на бренд, попадаем сюда - http://autokolesa.com.ua/tyres/amtel и путь у нас Главная / Шины / Amtel. Это уже сгенерировано роутером, который убрал "category" иначе визуально было бы http://autokolesa.co...ategory/amtel. Тем не менее, если пойти по "классическому" варианту, то он все равно работает, потому что мы предусмотрительные и пишем только качественные продукты
Далее кликаем на категорию Nordmaster, попадем сюда http://autokolesa.co...mtel/nordmaster и путь выглядит как хотел заказчик Главная / Шины / Amtel / NordMaster (Главная / Тип товара / Бренд / Модель ).
В итоге мы попадаем на страницу с тизерами 4 товаров в табличном виде, при это роутер делает 8 запросов: по 2 запроса на каждый айтем. Вроде немного. Но есть модели с большим количеством типоразмеров, от 30 и выше, это было 60 с лишним запросов и профайлер SQL явно показывал, что надо что-то делать. А сделано было вот что. Ввиду небольшого количества категорий первого уровня я жестко забил в роутер id категорий первого уровня, тем самым сэкономив 1 запрос на каждом уровне. При 30 запросах результаты стали приемлемые, а ввиду того, что категории первого уровня не меняются вообще, то клиент получил, что хотел, и с приемлемой скоростью работы, а я получил необходимость каждый раз восстанавливать модифицированный роутер при апдейте Zoo и теоретическую необходимость дорабатывать роутер, если клиенту вздумается добавить еще одну категорию первого уровня.
Вот теперь и думайте, надо ли такой ценой красивые "хлебные крошки" и красивые структурированные URL 
mindguru сказал(а) 08 Ауг 2013 - 17:10:
Кстати (ну это уж совсем оффтопик, просто к слову пришлось). Как Вы решаете проблему хлебных крошек? Поясню. Категории Zoo на моём сайте броузятся отдельным скриптом, с него же переход потом уже непосредственно на итем. Так вот, чтобы после перехода в хлебных крошках осталось название категории, обязательно нужно в ссылке указать Itemid пункта меню. Это означает обязательное создание пунктов меню по количеству категорий, что далеко не всегда бывает удобно. Что Вы посоветуете в этом случае?
Ну это известная проблема (фича?) ZOO. Вот официальный срач по этому поводу
Чтобы сделать нормально, а критерием нормальности я считаю вид: category_level_1_alias / category_level_2_alias / ... /item_alias , и не использовать сторонние компоненты, то есть только один путь - переписывать роутер под себя.
Метода простая. В роутере вы отслеживаете id категории айтема и начинаете из таблиц zoo_category_item и zoo_categories по полю parent "раскручивать" дерево категорий от текущего уровня вверх до корня. Каждый уровень - это 1 уточняющий наличие родительской категории SQL запрос. Если у вас 1 категория - 1 запрос, 2 категории - 2 запроса и т.д. Раскрутив категории в динамические массив, потом вы по сегментам можете "собрать" требуемый путь, чтобы было красиво. То же самое можно делать при помощи объектной модели ZOO , используя методы класса Item - getRelatedCategoryIds(), getPrimaryCategory(), getPrimaryCategoryId() и методов класса Category - hasChildren(), getParent(), getPathway().
У этого способа множество недостатков. Первый и самый важный: и при прямых запросах и при объектном программированни при количестве вложенности категорий более двух MySQL танцует ламбаду от навалившихся на него запросов на каждый генерящийся на странице линк. Если у вас 20 айтемов на странице категории 3ей вложенности - это +60 запросов. А если это 100 айтемов в табличном выводе с линками на "подробно"? Это уже 300. При высокой посещаемости проекта вам понадобится очень хороший сервер, да и то, не факт, что не будет космических лагов. Разработчикам сторонних роутеров пофиг - они продают коммерческое решение, не особо задумываясь о ресурсах пользователя, потому они акцентируют внимание на результат, а не на скорость работы продукта. Но смею вас заверить, приведенная мною методика с использованием SQL запросов - единственный путь получить требуемый результат, потому вы в любом случае получите нагрузку. Ну или надо линковать все категории и айтемы в меню, сохраняя иерархию. Думаю, что последний вариант для серьезного проекта не подходит.
Второй недостаток в том, что каждому айтему в ZOO вы можете присвоить несколько категорий. В этом случае вы получаете проблему множественности возможных путей.
Простой пример. Я начинающий сайтостроитель и не знаю что такое атрибуты товара, зато я научился делать категории и присваивать их в админке. Я продаю каски. Военные и строительные. Хаки и оранжевые. Я делаю категорию "По назначению" и в ней 2 подкатегории "Военные" и "Строительные", а потом еще делаю категорию "Цвет" и в ней 2 подкатегории "Хаки" и "Оранжевые". Товару "Строительная каска оранжевая" я присваиваю 2 категории - "По назначению/Строительная" и "Цвет/Оранжевые". Эта каска у нас отображается например в модуле ZOO Items. В данном случае линк на этот товар может иметь 2 абсолютно корректных пути - "По назначению/Строительная/Строительная каска оранжевая" и "Цвет/Оранжевые/Строительная каска оранжевая". Какой путь будет выбран - зависит от прописанного в роутере алгоритма: используется ли проверка множественности категорий, и если да, то какая именно запись принадлежности айтема к категории из zoo_category_item будет использована - та что, про назначение или та, что про цвета.
Думаю, что совокупность этих недостатков, в конечном итоге, и привела разработчиков ZOO именно к тому решению, которое мы видим в данный момент.
Иногда "продвинутые" SEF-помешанные клиенты все-таки настаивают, потому рождаются компромиссы. Пример с того же сайта
http://autokolesa.com.ua/tyres - имеем путь Главные / Шины (это из меню)
Далее кликаем на бренд, попадаем сюда - http://autokolesa.com.ua/tyres/amtel и путь у нас Главная / Шины / Amtel. Это уже сгенерировано роутером, который убрал "category" иначе визуально было бы http://autokolesa.co...ategory/amtel. Тем не менее, если пойти по "классическому" варианту, то он все равно работает, потому что мы предусмотрительные и пишем только качественные продукты
Далее кликаем на категорию Nordmaster, попадем сюда http://autokolesa.co...mtel/nordmaster и путь выглядит как хотел заказчик Главная / Шины / Amtel / NordMaster (Главная / Тип товара / Бренд / Модель ).
В итоге мы попадаем на страницу с тизерами 4 товаров в табличном виде, при это роутер делает 8 запросов: по 2 запроса на каждый айтем. Вроде немного. Но есть модели с большим количеством типоразмеров, от 30 и выше, это было 60 с лишним запросов и профайлер SQL явно показывал, что надо что-то делать. А сделано было вот что. Ввиду небольшого количества категорий первого уровня я жестко забил в роутер id категорий первого уровня, тем самым сэкономив 1 запрос на каждом уровне. При 30 запросах результаты стали приемлемые, а ввиду того, что категории первого уровня не меняются вообще, то клиент получил, что хотел, и с приемлемой скоростью работы, а я получил необходимость каждый раз восстанавливать модифицированный роутер при апдейте Zoo и теоретическую необходимость дорабатывать роутер, если клиенту вздумается добавить еще одну категорию первого уровня.
Вот теперь и думайте, надо ли такой ценой красивые "хлебные крошки" и красивые структурированные URL
Сообщение отредактировал Станислав: 08 August 2013 - 20:39
Тема закрыта
