Каталоги

Создание каталогов всего-на-свете - одна из наших любимых задач, и преимущества Fenrir.CMS тут особенно полезны.

Иерархия как "родная" для системы структура данных (все объекты системы формируют дерево) полволяет легко создавать классические каталоги любого уровня сложности.

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

Типизация разделов

В отличие от большинства систем, разделы каталога в Fenrir являются обычными объектами и могут относиться к произвольному типу данных. Благодаря этому получается создать модель данных, максимально близкую к реальному миру, а потому - простую и понятную.

Например, для автомобильного портала Millioncars.ru мы делали каталог, имеющий структуру "Раздел / Марка / Серия / Модель". Соответственно, каждый тип данных имеет свой характерный набор полей.

Для корпоративного сайта ГК "Русская Традиция" был реализован каталог продукции, имеющий структуру "Страна / Брэнд / Наименование / SKU", каждому уровню соответствует свой набор характеристик (как и в реальном мире).

Произвольные типы объектов

В Fenrir.CMS допустимый тип объектов не обязательно привязывается к ветви иерархии. Это полезно, когда в основу каталога ложится не тип объекта, а какой-либо другой признак.

Например, можно легко создать каталог со структурой "Страна / Производитель / Товары", где на последнем уровне будут расположены объекты разных типов.

Более того, объекты-товары можно складывать и в "Страну" (например, если производитель неизвестен). В этом смысле CMS не накладывает никаких ограничений - лишь бы модули front-end знали, как обрабатывать созданную структуру.

Сетевая структура

Часто бывает необходимо создать каталог, где каждому объекту соответствует больше одного родителя. Такая структура не является иерархией, однако реализовать ее на Fenrir.CMS вполне возможно.

Во-первых, существует встроенный механизм "ссылок" - можно создать ссылку на объект, при этом операции "чтения" ссылки будут выполняться так же, как если бы вместо нее существовал реальный объект, но при удалении ссылки объект не пострадает. В этом смысле "ссылки" очень похожи на "ярлыки" или "symbolic links".

Во-вторых, можно создать отдельный тип данных - "связку", содержащий поле-указатель на объект. Такой подход предоставляет возможность наделять "связки" дополнительными полями.

Например, необходимо создать каталог для доставки букетов в разных городах. При этом в каждом городе каждый букет может иметь свою цену (поскольку цветы покупаются у разных поставщиков). Тогда мы создаем тип данных "Букет в городе", содержащий поле-указатель "Букет", поле-указатель "Город" (можно привязать к родителю) и поле "цена". Таким образом, мы решаем проблему и избегаем дублирования данных.

"Псевдо-иерархия"

В некоторых случаях в качестве критерия рубрикации выступает одно из свойств объекта. Например, для сайта ассоциации "РОСЗАРУБЕЖСТРОЙ" мы создали каталог выполненных проектов, имеющий структуру "Вид работ / Страна / Проект". Можно было бы повторить такую структуру буквально, но тогда мы бы столкнулись с дублированием стран. Правильное решение: создать в панели администратора структуру "Вид работ / Проект", проекту добавить поле-ссылку "Страна", а затем переопределить URL-роутер, добавив правило разрешения адресов типа "/activity/country/object/" (+15 строк кода).