Вынашиваю идею tag/rule driven product content management. Это система управления товарами, основанная на двух концепциях: rule engine и tags/tag groups.
Никак не встречается ни заказчик, который хотел бы поэкспериментировать, ни готовое решение от кого-то со стороны. Вдруг вы знаете?
Мысль такая.
1. Товары (почти) не имеют характеристик. Они имеют неупорядоченные теги. Например, для того, чтобы указать, что товар красный, не нужно выбирать свойство “цвет” и выставлять ему значение красный. Нужно добавить тег “красный”. Система покажет список групп, в которых есть слово “красный” и нужно выбрать правильную группу (но можно не выбирать; это потом сделает специально обученный человек).
2. Теги организованы в группы. Один тег может принадлежать разным группам. Например, может быть группа “цвет” с тегом “красный”. В группы теги собираются уже после того, как они присвоены товару. Некоторые теги могут быть в разных группах. Например, цвет помады и цвет машины могут оба содержать слово “красный”, а тег “iphone” может принадлежать как группе “тип чехла”, так и группе “совместимо с”.
3. Некоторые группы тегов обязательны для всех товаров. Некоторые группы обязательны, только если есть теги из определенных других групп. Например, если есть тег из группы “тип аксессуара”, то система может потребовать выбрать что-то из группы “совместимо с”. Для этого используются динамические правила, например на Drools.
4. Некоторые группы несовместимы между собой. Это тоже определяется динамическими правилами, например на Drools. По сути, это правила валидации. Звучат они так: если тип товара – электронные часы, и нет тега из группы бренд, то вывести критикал мессадж, что нужно ввести бренд.
5. Для удобства администратора можно выбрать шаблончик, где группы уже красивенько собраны в формочку и есть всякие ниспадающие списки. Шаблончики конструируются на лету каким-нибудь главным администратором без привлечения программиста. Для ввода умных часов может быть один шаблончик, для ввода кроватей – другой. Сам админ может выбрать любой шаблончик, как и ввести любые теги, но система может ему помочь выбрать более подходящий. За это тоже отвечают правила. Выглядит это так: админ введет пару тегов, а система подскажет, что под эти теги и их значения попадают вот такие шаблоны (раз, два, три). Админ кликает на подходящий и заполняет дальше его. Шаблон не ограничивает админа. Он может ввести любые теги поверх тех, что есть в шаблоне. Или не заполнить какие-то поля (за заполнение отвечает не шаблон, а правила валидации – см. п. 4)
6. Такие характеристики как размер или вес содержат числа. Числа же тегами не представишь? На самом деле представишь, просто в этом случае указание группы обязательно. Выглядит это так: пользователь начинает печатать 135 мм, система показывает в выпадающем списке “Длина: 135 мм” и “Ширина: 135 мм”. Какие группы показывать на введенное значение управляют динамические правила, например, на Drools.
7. Таким образом, тег имеет тип. Он определяется либо автоматически, при вводе, либо устанавливается правилом, например, на Drools, как только выбрана группа. Например, все значения группы “Длина” – числа.
8. Понятия дерева категорий нет. Категории тоже теги. Просто они объединены в группу “Категории”, “Электроника”, “Мобильные телефоны”.
9. Если тег не находится ни в одной из групп, он может быть привязан к товару без группы, либо админ может указать любую группу вручную. В этом случае в следующий раз этот тег будет уже показываться с этой привязанной группой.
10. Есть специальные менеджеры тегов, которые видят какие теги появляются и к каким группам привязываются. Они могут удалять теги из групп, создавать новые группы, переименовывать и т.д.
Вверху много где упомянуты правила. Правила – это структура из двух частей: условия и действия. Условия, а их может быть несколько, оперируют группами, тегами и их значениями. Действия – что выводить пользователю в качестве подсказки, изменение состояние облака тегов. Действия могут также удалять, изменять или добавлять теги автоматом. Например, качество заполнения товарных данных может быть значнием из группы “Product data quality” и иметь какую-то шкалу.
Группы имеют свойства “отображать на сайте”, “помещать в фасет на поиск”, “readonly для админа” и т.д. К группам может быть привязан функционал отображения значений.
В эту концепцию пока не очень ложатся идеально медиаобъекты, как картинки или видео. Если их делать по тому же принципу, то сначала их загружаешь, потом привязываешь к товару, а потом выбираешь группу, которая связана с типом изображение. Опять же, в ход идут правила на Drools для отбора подходящих групп (например, исходя из типа загруженного медиаассета) или для валидации (например, размер изображения слишком мал для группы).
Также есть опасение, что будет сложно управлять сотнями правил, если столько накопится, и будет сложно сделать интерфейс для сотен групп и тысяч/десятки тысяч значений. Но вроде это все фиксабл.
Timofey Shikolenkov ?
Being in America 