Drupal Commerce как лучше сделать товар?

Аватар пользователя AlekseyBond AlekseyBond 3 апреля 2012 в 12:51

Добрый день!

Подскажите как лучше сделать,
делаю интернет магазин одежды на Drupal Commerce,
как разбить товар: к примеру женская одежда, мужская одежда или лучше разбить на категории брюки, майки, куртки и т.д.?

Возможно ли будет объединить в одной ноде при формировании продукт дисплей размер и цвет товара?

Комментарии

Аватар пользователя AlekseyBond AlekseyBond 5 апреля 2012 в 18:10

Хочу сделать выбор размера одежды в ноде, но не создавая дополнительный товар. Например создал товар джинсы, а в ноде указал несколько размеров этого товара на выбор. Вопрос реализуемое ли это в Drupal Commerce?

Аватар пользователя multpix multpix 5 апреля 2012 в 20:15

имхо:
словарь sex
муж жен унисекс
словарь age
взрослый детский
словарь weartype
рубахи брюки куртки и тд
словарь material
словарь brand

это референсами в поля отображения товара
по ним и фильтровать и меню
к товару поле список текст в него размеры - разрешить ему быть атрибутом при добавлении в корзину

к отображению товара - поле ссылка на товар (множественный выбор значений)

создавая отображения товара добавлять несколько товаров с разными размерами

делать

"AlekseyBond" wrote:
почему нет ответов?

пациму!!!

))

успехов в работе.

Аватар пользователя AlekseyBond AlekseyBond 5 апреля 2012 в 22:05

Спасибо, так и сделал
Только непонятно как сделать выбор по размеру не забивая товар в товары,
забил один товар в товары, а потом сделать выбор по размеру уже в ноде?
Сейчас приходится забивать товар с размерами в товары,
т.е. джинсы M, джинсы ХL, джинсы XXL, а потом объединять все товары в одной ноде и делать выбор по размеру, а как сделать чтобы в товары забить один раз джинсы, а в ноде сделать выбор по размеру?

Аватар пользователя graker graker 5 апреля 2012 в 22:43

AlekseyBond wrote:
Сейчас приходится забивать товар с размерами в товары,
т.е. джинсы M, джинсы ХL, джинсы XXL, а потом объединять все товары в одной ноде и делать выбор по размеру, а как сделать чтобы в товары забить один раз джинсы, а в ноде сделать выбор по размеру?

По-умолчанию только так и надо.
Как быть, например, если товар с размером XXL раскупят?

Аватар пользователя AlekseyBond AlekseyBond 5 апреля 2012 в 22:50

"graker" wrote:
Как быть, например, если товар с размером XXL раскупят?

Это не проблема сейчас, учета остатков на складе не будет

Аватар пользователя multpix multpix 5 апреля 2012 в 23:13

"AlekseyBond" wrote:
Это не проблема сейчас

ничто не проблема))
ошибка в фундаментальном конструктивном решении - не проблема....
ведь всегда можно все переделать с ноля без ущерба сроку и бюджету...

и следующий - опять с ноля клепать под новые изье..

))))))))

универсальный подход
есть в риале товар (цена характеристики) - вот и в коммерце товар.
штанья M и XXL - разные вещи по сути))
а то что они лихо группируются в один дисплей ибо обладают всеми общими признаками кроме размера - так это ГУД!!

Делай как разработчики коммерца рекомендуют, а потом обогати функционал своими наработками
вот тогда и мудруй и с автосозданием дисплеев или товаров, с удобными отчетами и редакторами контента для манагера и тд.

тут уж негде крутиться - если это не 25й магаз склепанный на коммерце - для себя и окружающих дешевле проплыть по течению ))

Аватар пользователя vmogila vmogila 25 мая 2012 в 2:19

multpix wrote:

универсальный подход
есть в риале товар (цена характеристики) - вот и в коммерце товар.
штанья M и XXL - разные вещи по сути))

Это замечательно... Но в товаре есть картинки. Да, для желтых и малиновых штанов нужны отдельные картинки, но зачем мне разные картинки для желтых штанов размера M и желтых штанов размера L? Ведь новый product требует загрузки своей собственной картинки. А если у меня в товаре 5 картинок для желтых штанов (с разных сторон)? Умножим на семь размеров - 35 картинок. Хотя реально нужно только 5. А ImageCache сделает три размера картинки и их будет 105. 105 изображений желтых штанов!!! Ведь 5 картинок - это обычная ситуация для хорошо сделанного магазина. Неужели это нормальная практика: плодить множество копий одной картинки? Как-то некрасиво. Как быть?

Аватар пользователя graker graker 25 мая 2012 в 9:20

vmogila wrote:
Это замечательно... Но в товаре есть картинки. Да, для желтых и малиновых штанов нужны отдельные картинки, но зачем мне разные картинки для желтых штанов размера M и желтых штанов размера L? Ведь новый product требует загрузки своей собственной картинки. А если у меня в товаре 5 картинок для желтых штанов (с разных сторон)? Умножим на семь размеров - 35 картинок. Хотя реально нужно только 5. А ImageCache сделает три размера картинки и их будет 105. 105 изображений желтых штанов!!! Ведь 5 картинок - это обычная ситуация для хорошо сделанного магазина. Неужели это нормальная практика: плодить множество копий одной картинки? Как-то некрасиво. Как быть?

Commerce BPC поставить.

Аватар пользователя Andruxa Andruxa 5 апреля 2012 в 23:42

С product и нодой-дисплеем вроде бы разобрались, позволю себе немного пофлудить.

Итак, DC-way предполагает, что особенности товара (product) хранятся в его филдах, а в ноде-дисплее они группируются виджетом одноимённого филда.

Например - магазин по продаже футболок, product - это непосредственно футболки, каждая имеет 2 поля-атрибута: цвет и размер.
Хочется сделать фильтры в представлении-каталоге, чтобы покупатель мог сформировать свой запрос: "покажите мне все футболки белого цвета размера XL"

Поскольку представление выводит ноды-дисплеи, а не сами product, то выборка становится достаточно сложной: нужно отфильтровать ноды, которые не ссылаются на product, имеющие определенный цвет и размер.

Второй пример - блок "самые продаваемые товары".
Следуя логике DC, сначало надо найти N product, количество которых максимально среди оплаченных заказов, а потом -=tada.wav=- надо найти ноды-дисплеи, содержащие ссылки на эти product.

Причем, ситуация может усугубляться тем, что никто не запрещает создавать одному product несколько нод-дисплеев, например шнур USB A-B может преподноситься как "шнур для передачи данных от фотоаппарата SONY к ноутбуку" ну и т.д. - бывают такие юзабилити-френдли магазины для идиотов.

В этот момент мой диссонанс становится всё более когнитивным - а надо ли было мудрить сущность product, если её использование в ситуациях, хоть немного отличающихся от типовых, тянет за собой столько неудобств?

Что думаете?

Аватар пользователя graker graker 5 апреля 2012 в 23:49

Andruxa wrote:
Поскольку представление выводит ноды-дисплеи, а не сами product, то выборка становится достаточно сложной: нужно отфильтровать ноды, которые не ссылаются на product, имеющие определенный цвет и размер.
Ну тут как я понимаю во вьюху вставляется отношение Referenced Product и для этого отношения включаются два фильтра.
Не очень просто из-за множественного поля, но сделать кажись можно.

Quote:
Следуя логике DC, сначало надо найти N product, количество которых максимально среди оплаченных заказов, а потом -=tada.wav=- надо найти ноды-дисплеи, содержащие ссылки на эти product.
С бэкреференсами на товары сейчас пока вроде туго, да. Хотя видел где-то подвижки.

Аватар пользователя multpix multpix 6 апреля 2012 в 0:00

"Andruxa" wrote:

в самое яблочко)

с появлением product возникло вполне обдуманное разделение на витрину и бухгалтерию,
типовые задачи - 90% всех задач))

для меня коммерц понятен и удобен - правда пилить под него много,
но буду пилить именно под него а не под убер ))

Аватар пользователя Andruxa Andruxa 6 апреля 2012 в 0:41

я воспринял в своё время появление product как материализацию SKU из уберкарта, тут всё хорошо и правильно
но вот дальнейшее наращивание фичей непосредственно в product - штука сомнительная, имхо

что касается бухгалтерии - ей надо обмениваться ценами, остатками и заказами с CMS, остальное - от лукавого
навороты product тут не только не нужны, но и порою вредны

Аватар пользователя AlekseyBond AlekseyBond 28 мая 2012 в 0:06

"vmogila" wrote:
Как быть?

Я картинки на складе не вставлял, а поставил их уже в ноде и описание товара там же
Но если захотите, чтобы картинки товара отображались в корзине, то такой вариант не подойдет, если не ошибаюсь

Аватар пользователя multpix multpix 28 мая 2012 в 0:16

"AlekseyBond" wrote:
Но если захотите, чтобы картинки товара отображались в корзине, то такой вариант не подойдет, если не ошибаюсь

Подойдет такой вариант.
Более детально обсуждали не так давно)

однако сие не снимает вопроса поднятого vmogila
сижу вот теперь, кручу, как его кошерно то сделать,
зачем только прочел ..
)))

Аватар пользователя graker graker 28 мая 2012 в 9:00

А я на всякий случай повторю: Commerce BPC решает данную проблему. Только что специально создал товар с четырьмя размерами и тремя разными картинками. В Commerce BPC на сайте появилось ровно 3 файла изображения. Не 4*3=12, а 3.

А есть еще "упрощенка" http://drupal.org/project/commerce_option - которая позволяет отойти от принципа "отдельная сущность product для каждой комбинации атрибутов". Но конечно пользоваться плюсами принципа тогда тоже нельзя. И если скомбинировать Commerce BPC и Option - можно сделать цвет атрибутом, а размер - опцией.

Аватар пользователя petu petu 5 июля 2012 в 13:23

graker wrote:
А есть еще "упрощенка" http://drupal.org/project/commerce_option - которая позволяет отойти от принципа "отдельная сущность product для каждой комбинации атрибутов". Но конечно пользоваться плюсами принципа тогда тоже нельзя. И если скомбинировать Commerce BPC и Option - можно сделать цвет атрибутом, а размер - опцией.

А Вы реально пользователись этим модулем? Судя по описанию, он решает проблему с размерами-цветами без создания новых артикулов. Но реально - у меня получается какая-то хрень :(. Поле в товаре появляется. Но забивать размерами при добавлении товара в магазин возможности нет. И так покрутил и так, и "по колесу пинал" - "не выходит каменный цветок" :(. Помогите советом?

Аватар пользователя petu petu 5 июля 2012 в 16:40

Нашел для себя решение, чуток модифицировав код, предложенный другим участником. Суть: при помощи hook_form_alter() исключить из списка значения, которые недоступны для выбора (их нет в наличии).
Решение описал тут: