Цитата |
---|
Вот этот момент меня как раз и волнует. В примере который я привел, инфоблок должен находится на 2 уровне вложенности.Если я правильно понял, не получится построить красивый путь к группе: группа1 -> группа 1.2 -> группа 1.2.1, если группа 1.2.1 является инфоблоком. Как поступать в таком случае? |
Почему же не получится? Самое простое в этом случае, вручную (физически на диске) создать нужные надразделы в виде разделов сайта, а в них на нужном уровне на страницах расположить простые или комплексные компоненты каталога для соответствующих инфоблоков.
Если хочется большей юзабильности, можно, например, кастомизовать комплексный компонент каталога, чтобы он обрабатывал адреса с учетом
надструктуры (группа1 -> группа 1.2) каталога заданной, например, в виде специального меню или в виде отдельного инфоблока описаний разделов.
Еще следует учесть, что стандартный комплексный компонент bitrix:catalog не поддерживает иерархическую структуру URL, его надо переделывать под это. Это я к тому, что если Вы хотите иерархическую надструктуру, то, возможно, хотите и иерархическое отображение структуры инфоблока в урле.
Цитата |
---|
В данном случае, можно ли как то к группе привязать определенные свойства для фильтрации. И как это лучше сделать? |
Можно, например, прописав нужные данной группе (и ее потомкам) свойства в специально заведенное пользовательское поле, про которые Вы дальше упомянули. Ну и компонент фильтра (или, может быть, только шаблон, или даже просто его вызов) дописать, чтобы понимал их.
Можно, и думаю, не очень тяжело во всех смыслах, просто поработать над компонентом фильтра (bitrix:catalog.filter), чтобы он проверял, какие конкретные свойства имеют значения у товаров этой группы и выводил только их. Только это дело надо правильно закэшировать, чтобы не было существенной нагрузки, а можно скомбинировать с предыдущим вариантом.
Опять таки, это можно сделать и прямо в шаблоне bitrix:catalog, где вызываются простые компоненты каталога и фильтр в их числе. Сложно, не глядя, сказать, где и как это лучше сделать. Разработчик должен решать в процессе.
Плюс, если нужен список сравнения, его тоже нужно кастомизировать.
Цитата |
---|
Ни каждый разработчик может правильно выбрать архитектуру каталога, подумав при этом об оптимизации производительности. |
Разработчик все же должен понимать, что он делает, а если он хорошо понимает какую-то методику, то пусть уж лучше ей пользуется, чем навязанной. Это IMHO, конечно. Выбирать из различных очевидных вариантов тоже тяжело.
Что касается производительности, то тут многое от многого зависит (от самой структуры каталога, например). У меня в этом плане опыта совсем немного, не могу сказать однозначно, какой вариант (одним инфоблоком, или несколькими) выгоднее, думаю, для небольшого проекта разница невелика.
А вообще, лучше плясать от дизайна структуры сайта, юзабилити и просто дизайна, Битрикс это позволяет. Хотя вопрос сил и средств может встать и тут и там.