Если необходимо каждому товару (или т.п. сущности) назначить произвольный список характеристик со значениями.
Как-то однозначно организовать ввод данных характеристик, чтобы потом по ним можно было фильтровать, сортировать, группировать связанные с ними товары, то способ такой..
Термины и определения:
1.Справочник - некий предопределенный список значений, например список цветов, список размеров одежды и т.п.
Обычно храниться в словаре таксономии или поле типа Список
2.Произвольное значение - значение типа число или строка, для которого нет смысла хранить "предопределенные значения", например вес, длина, ширина и т.п. Вводится пользователем вручную в поле типа "текст".
3.Единицы измерения - необходимы для Произвольных значений для указания их единиц измерения ,
например ширина: 20 см, длина: 1.5 м и т.п.
Наименования характеристик логичнее хранить в словаре таксономии
есть 2 типа характеристик:
1. Тип значения - Справочник.
Поля:
- Наименование характеристики (Справочник)
- Значение характеристики (Справочник)
2.Тип значения - Произвольное значение
Поля:
- Наименование характеристики (Справочник)
- Значение характеристики (Произвольное значение)
- Единица измерения (Справочник)
Итого для описания характеристики получается 2 сущности с разными наборами полей.
Добавляем в товар многострочное поле Характеристик типа entity reference (ссылка на сущность)
И все..
Мы можем добавлять к товару любое кол-во характеристик с любыми необходимыми значениями.
Если список типов товаров на сайте достаточно большой и необходимо как-то систематизировать ввод характеристик типов товаров, тот тут как-раз и можно применить метод, похожий на наследование.
Товары обычно категоризируют при помощи иерархического каталога.
Обычно этот каталог строиться при помощи словаря таксономии (пример):
1.Одежда
- Верхняя
- - Пальто
- - Шубы
2.Мобильные устройства
- Сматрофон
- Планшет
и т.п.
Т.е. что получается.
У всех товаров раздела Одежда есть характеристика: Размер
У всех товаров раздела Одежда - Верхняя есть характеристика: Сезон
У всех товаров раздела Одежда - Верхняя - Шубы есть характеристика: Тип меха
У всех товаров раздела Мобильные устройства есть характеристики: операционная система, тип процессора, размер оперативной памяти и т.п.
Т.е. можно заранее назначить разделам каталога список необходимых характеристик, по иерархии от общих к все более индивидуальным.
Т.е. просто добавив к термину таксономии каталога многострочное поле "Список характеристик" для ввода наименования характеристик, используемых для товаров данного раздела.
И при вводе товара в определенный раздел каталога сразу выводить на форму список характеристик, специфичных для данного раздела и его "родителей" выше по иерархии (плюс любые произвольные)
В краце как-то так.
Теоретически, что-то подобное можно и мышкой накликать и немного доработать специальным модулем.
Но было бы удобнее, если бы весь данный функционал предоставлялся специальным модулем.
Сейчас как раз на одном проекте такое "пишется".
Когда-нибудь, возможно скоро будет готово-)
1Andres Написал:
Большое спасибо.
Только в голове мне трудно исполнить этот псевдокод. )
Не понимаю как работают следующие моменты (после этого я потерял логическую нить):
Добавляем в товар многострочное поле Характеристик типа entity reference (ссылка на сущность)
И все..
Понимаю, что такое "многострочное поле Характеристик типа entity reference". Не понимаю как этим пользоваться в данном случае..
то тут как-раз и можно применить метод, похожий на наследование.
...
И при вводе товара в определенный раздел каталога сразу выводить на форму список характеристик, специфичных для данного раздела и его "родителей" выше по иерархии (плюс любые произвольные)
Что подразумевается под словами "выводить на форму" не понял.
И как следствие не могу представить ответы на 3 волнующих вопроса:
- Как можно фильтровать, сортировать, группировать такие товары?
- Как выводить эти характеристики на странице товара (если это возможно, важно в определённом, единообразном для всех товаров, порядке)?
- Как выводить часть заданных характеристик в листинге товаров (например в листинге нужно только самое необходимое для краткости: Диагональ экрана смартфона и Объём оперативной памяти)
В свободное время попробую сделать прототип используя этот подход, должно стать яснее.
Если можно, скиньте пожалуйста ссылку на пример каталога с фильтром, построенный на этих принципах (можно и в ЛС).
И ещё вопрос: Этот принцип улучшает производительность? в сравнение с:
Использованием большого кол-во типов материалов (у меня 70), и использования вместо ваших принципов: Метод создания кучи технических характеристик отдельными полями (у меня 570, некоторые из них пересекаются по типам, но не так уж и много, некоторые дублируются (знаю это большой грех, надеюсь дойдут руки поправить)).
схемка данных https://drive.google.com/file/d/15r3wTbmiSqxrqiaqts3AdA0Uz_SzQZfc/view?u...
Понимаю, что такое "многострочное поле Характеристик типа entity reference". Не понимаю как этим пользоваться в данном случае..
Тот же принцип как и работа поля модуля Paragraphs.
Поле характеристики товара имеет тип Ссылка на сущность
Может ссылаться на типы сущностей
- Характеристика "Справочник"
- Характеристика "Значение"
Если необходимо добавить к товару характеристику Цвет
добавляем в поле Характеристики ссылку на сущность типа Характеристика "Справочник"
в добавленной сущности:
в поле Наименование выбираем из списка "Цвет"
в поле Значение выбираем из списка "Красный"
Если необходимо добавить к товару характеристику Длина
добавляем в поле Характеристики ссылку на сущность типа Характеристика "Значение"
в добавленной сущности:
в поле Наименование выбираем из списка "Длина"
в поле Значение вводим "123"
в поле Единицы измерения выбираем из списка "см"
Что подразумевается под словами "выводить на форму" не понял.
В категории каталога храниться список Наименований характеристик товаров категории , например:
- размер
- цвет
- материал
При добавлении товара в категорию, автоматически(программно) добавляем на форму добавления товара характеристики с наименованиями:
- размер
- цвет
- материал
А пользователь только проставляет их значения
В свободное время попробую сделать прототип используя этот подход, должно стать яснее.
1. Рекомендую для сущностей Характеристики использовать модуль Paragraphs или Field Collection
ноды для характеристики слишком "много"
2.Возможно может пригодиться модуль Inline Entity Form ( https://www.drupal.org/project/inline_entity_form )
И ещё вопрос: Этот принцип улучшает производительность? в сравнение с:
Это не про "производительность"..
Это про оптимальную структуру данных.
Нет необходимости добавлять 70 типов материалов
и 570 характеристик.
Достаточно ОДНОГО типа материала
ДВУХ типов материалов для хранения данных характеристик
И нескольких словарей таксономии для хранения предопределенных значений .
Т.е. при таком способе "расширение" списка типов товаров можно осуществлять банальным импортированием справочных данных (словарей таксономии) и непосредственно самих товаров.
А производительность..
Увеличение производительности достигается правильной организацией работы кэша.
Если товар не изменяется по нескольку раз в час, зачем каждый раз рендерить вывод товара?
Достаточно это сделать 1 раз после добавления-изменения товара.
Изменился товар
Сбросился кэш
При следующем выводе товара на страницу отрендирился и закэшировался вывод.
А далее показываем данные из кэша, пока товар не изменится.
Источник комментарий: https://drupal.ru/node/70255#comment-722816 от пользователя Orion76
