[Rodogor]

Здравствуйте. Давайте поговорим
Предлагаю пообсуждать, пофантазировать на счёт одной очень интересной темы.... Говорят, мол правильно заданный вопрос уже несёт в себе ответ.

Никак не могу понять как лучше делать связку размер-цвет для нескольких товаров. Дать пользователю возможность выбора цвета-размера. Да ещё и предположим цены меняются в зависимости от цвета-размера.

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

Итак, у нас такая задача: есть следующие товары
ботинки синии 31 размер, ботинки синии 32 размер, ботинки синии 33 размер,
ботинки зелёные 31 размер, ботинки зелёные 32 размер, ботинки зелёные 35 размер.

Для каждого товара нам нужно хранить количество на складах. Складов несколько. При продаже товара нужно понимать какой конкретно товар продался, с какими параметрами размер-цвет.

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

Как лучше на umi сделать эту связку ?

Я лично вижу так:

1) выбираем один из объектов и привязываем к нему остальные ссылкой типа дерево. Остальные объекты выключаем. Остальные объекты нам нужно хранить для того, что бы считалось их количество и т.п....
Кликая по цветам/размерам на заднем фоне подменяем id объектов для добавления в корзину, ну и покупаем уже нужный товар (ведь через udata можно получить данные выключенных объектов по id). Но блин ссылка в корзине будет весьти к выключенному объекту... Ну обдумать можно.

Я склоняюсь к этому варианту, но мне кажется будет много запросов. Можно конечно раз в день/после синхронизации заполнять в основном объекте поля, но как-то не знаю....

2) создаём КАТАЛОГ "ботинки", в который уже помещаем эти все ботинки. 
Пользователь выбирает ботинки, подменяем ему id для добавления в корзину, ссылки из корзины видут на нужный объект, но он не будет связан с остальными объектами... Логично ведь, если выбирали ботинки, были различные цвета - вернуться надо туда же и что бы размер/цвет был уже выбран. Ну вроде можно сделать так, что когда module="catalog" method="object" - анализировать нужно ли получать parentId и делать getObjectList...... Т.е. нужно как-то определить, что делать - выводить только этот объект, получать родителя и искать "соседей",.....
Вроде бы это всё даже логичнее.... url конечно бешенный будет. каталог/объект...
Да и если один товар будет - для него так же нужно создавать категорию и кидать туда...  Или можно и без этого обойтись.
Или сделать вообще такую комбинацию -
ботинки\синие 31
ботинки\синие 32
ботинки\синие 33
ботинки\зелёные 32
ботинки\зелёные 33
ботинки\зелёные 35
балетки(объект каталога)
сланцы(объект каталога)

Написать макрос, смесь GetObjectList и getCategoryList, в котором будут выводиться И категории И объекты (они ведь суть есть наследники/дети для верхней категории), это вроде не сложный кастом.

3) используем опционные свойства в umi, через составные свойства. Вообще не вижу это решение. Всё, что связано с umi приходится переписывать и делать самому, поэтому пытаться понять это мой мозг просто отказывается.

Создаём тип данных "характеристики" с полями [цвет][размер][цена](ну или цену задать можно уже в объекте), разрешаем пользовать как справочник. Добавляем в наш тип данных, который объект каталога. Заходим, выбираем цвет-размер, дописываем цену. А как привязать к какому-либо складу ? А если складов несколько ?
Вот тут я вообще уже не вижу....

[Vladimir]

1)

выбираем один из объектов и привязываем к нему остальные ссылкой типа дерево. Остальные объекты выключаем

Да, но теперь давайте представим как менеджер, тихо матерясь, заполняет каталог из 1500 ботинок, каждый раз открывая неторопливое окошко "ссылки на дерево".
Выключать работающие товары нехорошо, потому что для редактора сайта выключенная страница субъективно значит - ненужная. Кто-то обязательно удалит "все лишнее".

2)

создаём КАТАЛОГ "ботинки", в который уже помещаем эти все ботинки.

Мне это уже больше нравится, но возникает вопрос как показывать обобщенный тип "ботинки" с модификациями цвета.
Если бы каждый цвет можно было представлять отдельным товаром, то все просто
"/каталог/ботинки/?fields_filter[vendor][3505]=3505&fields_filter[razmer][4206]=4206&fields_filter[color][58286]=58286&order_filter[price]=1"
при этом все меню на сайте, навибар, выборки - делать кастомно.
Но мы же хотим группировать цвета. В итоге все равно упираемся в вариант 1) тем, что нужно делать связку.

3) Опции в ЮМИ какаие-то недоделанные, поэтому о них и не думаем.


В свете этого мне стало интересно - а как в Маркет правильно выгружать такой каталог?  Эти различные размеры передвать туда как самостоятельные объекты или есть возможность как набор параметров одного объекта?

[Rodogor]

Я предлагал абстрагироваться от этих моментов, но всё же...

Да, но теперь давайте представим как менеджер, тихо матерясь, заполняет каталог из 1500 ботинок, каждый раз открывая неторопливое окошко "ссылки на дерево".
Выключать работающие товары нехорошо, потому что для редактора сайта выключенная страница субъективно значит - ненужная. Кто-то обязательно удалит "все лишнее".

Для 8-ой 1с я написал кастомную выгрузку, которая для характеристик создаёт объект. Там ведь ид характеристики Ид-Родителя#Ид-характеристики. Вот я и создаю их... Получаю родителя, забираю с него все параметры нужные для создания объекта, только id в 1с указываю Ид-Родителя#Ид-характеристики.  Ну и остаётся их прявазать ссылкой типа дерево к родителю (ИД родителя ведь тоже рядом есть).

Для 7-ой 1с - думаю про неё можно забыть. Не знаю как там это выглядит, только на днях писал выгрузку под неё - но забирал только название, количество и цену.
Хотя вроде я уже столько пропарился с этим, что любой формат выгрузки восприму Вроде с 7-кой umi не поддерживает интеграцию... У меня кажется поддержало

2)

создаём КАТАЛОГ "ботинки", в который уже помещаем эти все ботинки.

Мне это уже больше нравится, но возникает вопрос как показывать обобщенный тип "ботинки" с модификациями цвета.
Если бы каждый цвет можно было представлять отдельным товаром, то все просто
"/каталог/ботинки/?fields_filter[vendor][3505]=3505&fields_filter[razmer][4206]=4206&fields_filter[color][58286]=58286&order_filter[price]=1"
при этом все меню на сайте, навибар, выборки - делать кастомно.
Но мы же хотим группировать цвета. В итоге все равно упираемся в вариант 1) тем, что нужно делать связку.

Я не понял, так ведь каждый цвет и размер действительно представляется объектом.

Про кастомность - не знаю у кого как, но я постоянно упираюсь в то, что писать нужно кастомы.... Крупный проект никак не закончу - там кастомы на 90%. UDATA, UPAGE и UOBJECT не тронуты За-то чую ещё немного и скажу - а зачем вообще покупать лицензию, всё можно на фри собрать. И это umi меня довели до такого, из обычного пользователя делают быдлокодера. научили на свою голову

Огорчает, что я реально поступаю так - чем вылавливать имеющиеся глюки в коде, я лучше поимею много гемороя на отладке, но будет код который я полностью знаю. Но я его естественно не поддерживаю потом.. Если у umi и выйдет что-то нормальное - у меня уже врядли...

Хотя их обновления тоже сильно улыбают.... Обновил - всё отвалилось нафиг. Макрос EditUserBlogs который получает id блога 'new' если создаётся новый ВДРУГ получил приобразование int - $blogId=(int)getRequest('param0');
Соответственно blogId стал равным 0 в случае нового блога, т.к. там string 'new'.
Писал в СЗ, звонил, объяснял - ощущение было что сотрудник от меня впервые услышал про то, что такое вообще может быть, про какое-то приведение типов и т.п.....
В итоге больше не обновляюсь.
И даже критические ошибки стараюсь править сам - им писать бесполезно. Сначала по каждому косяку писал, ошибки в документации и т.п... А потом надоело.

3) Опции в ЮМИ какаие-то недоделанные, поэтому о них и не думаем.


В свете этого мне стало интересно - а как в Маркет правильно выгружать такой каталог?  Эти различные размеры передвать туда как самостоятельные объекты или есть возможность как набор параметров одного объекта?

Я с опциями сам ещё не работал, но вот думаю небольшой магазин без обратной синхронизации с 1с сделать на опциях. 
На мой взгляд использовать объекты нужно когда необходимо хранить информацию по нескольким складам. В составных полях как-то тяжело это всё сохранить.
Я думаю так сделать - пользователь(пользователь для меня - администратор магазина) ручками выбрал связки цвет-размер, потом нажал кнопку в админке/сработал крон и пробежался по всем объектам каталога. Те, у кого есть ссылки на связанные товары - получил ИД связанных товаров и выключил их, что бы они не отсвечивали в ObjectList и т.п.



Может быть стоит нормально всё сформулировать и таки написать в СЗ, они вроде как должны знать как лучше реализовать ?...

[Vladimir]

Для 8-ой 1с я написал кастомную выгрузку, которая для характеристик создаёт объект. [..] Для 7-ой 1с - думаю про неё можно забыть.

))))))  Я про 1С вообще не думал, поскольку мои клиенты каталог ведут в экселе. А после битрикса упоминание 1С в меня вселяет самые нехорошие предчувствия.

Про кастомность - не знаю у кого как, но я постоянно упираюсь в то, что писать нужно кастомы.... [...] За-то чую ещё немного и скажу - а зачем вообще покупать лицензию, всё можно на фри собрать. И это umi меня довели до такого, из обычного пользователя делают быдлокодера. научили на свою голову

Аналогично

Огорчает, что я реально поступаю так - чем вылавливать имеющиеся глюки в коде, я лучше поимею много гемороя на отладке, но будет код который я полностью знаю. Но я его естественно не поддерживаю потом.. Если у umi и выйдет что-то нормальное - у меня уже врядли...

Именно так, тем более, что исправленные глюки вернутся после обновления. А нормальное - тоже выйдет, с ростом практики.

Хотя их обновления тоже сильно улыбают.... Обновил - всё отвалилось нафиг. Макрос EditUserBlogs который получает id блога 'new' если создаётся новый ВДРУГ получил приобразование int - $blogId=(int)getRequest('param0');
Соответственно blogId стал равным 0 в случае нового блога, т.к. там string 'new'.
Писал в СЗ, звонил, объяснял - ощущение было что сотрудник от меня впервые услышал про то, что такое вообще может быть, про какое-то приведение типов и т.п.....
В итоге больше не обновляюсь.
И даже критические ошибки стараюсь править сам - им писать бесполезно. Сначала по каждому косяку писал, ошибки в документации и т.п... А потом надоело.

В СЗ работают не те, кто вносит изменения в код. Сотрудник вполне мог не знать.  А вот то, что разработчики этого не учли - это нехорошо(
Тоже стараюсь не обновляться.

Может быть стоит нормально всё сформулировать и таки написать в СЗ, они вроде как должны знать как лучше реализовать ?...

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

[admin]

летопись печали да и только)

по поводу изначальной темы для фантазий

Никак не могу понять как лучше делать связку размер-цвет для нескольких товаров. Дать пользователю возможность выбора цвета-размера. Да ещё и предположим цены меняются в зависимости от цвета-размера.

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

в итоге в админке у нас получиться такая структура
-раздел с обувью (раздел каталога)
--обувь_1 (относиться к базовому типу "раздел каталога", при этом являясь подтипом "псевдотовар", по которому мы понимаем что его надо выводить как товар)
---обувь_1-синяя (относиться к базовому типу "объект каталога", при этом являясь подтипом "псевдовариация", по которому мы понимаем что его надо выводить как вариант цвета и размера, причем цвет это поле типа выпадающий список, а размер это составное поле)
---обувь_1-красная (относиться к базовому типу "объект каталога", при этом являясь подтипом "псевдовариация", по которому мы понимаем что его надо выводить как вариант цвета и размера, причем цвет это поле типа выпадающий список, а размер это составное поле)

в итоге пишем шаблоны (естественно на xslt) для страниц "псевдотовар" чтобы он выглядел как товар и выводил все свои дочерние страницы, как цвет и размер, при переключении цвета или размера меняются скрытые поля в которых указываем id "псевдовариации" и опционный id размера, которые использует кнопка "купить"

пишем шаблон для страницы "псевдовариация", чтобы при просмотре данной страницы происходил обязательный редирект на родителя, то есть на "псевдотовар"

можно также "псевдовариации" запрещать к индексации и поиску средствами самой umi (галочки соответствующие проставлять, автоматом или вручную)

в корзине делаем переделку, чтобы ссылка на "псевдовариацию", заменить на "псевдотовар"

Все поля необходимые для фильтра дублируем в псевдотоваре и меняем их по событиям типа сохранения\изменения "псевдовариации"

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

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

P.S. выгрузки из 1с также делаются без жесткой кастомизации, надо только грамотно поправить xsl файл, который формирует umidump xml чтобы он создавал правильную псевдо структуру каталогов и товаров


p.p.s. по поводу кастомов и их большого количества... да что тут говорить... конечно много их пишется, но почему я не перескакиваю на какие-то другие системы, так это потому что в umi есть то что мне нравиться что не говорите, а удобство работы в админки и логика заложенная в основы самой системы, куда приятней чем у многих других, а переделки меня не покидали даже тогда когда я садился за typo3 или wp...

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

[BaceH]

пишем шаблон для страницы "псевдовариация", чтобы при просмотре данной страницы происходил обязательный редирект на родителя, то есть на "псевдотовар"

можно также "псевдовариации" запрещать к индексации и поиску средствами самой umi (галочки соответствующие проставлять, автоматом или вручную)

второй абзац делать не стоит, в "псевдовариации" идет основная информация о товаре, а метод отображения этой информации описан в первом абзаце.

Rodogor в теме указана связка "размер-цвет", но в процессе обсуждения также добавилась цена и количество на складе.
Автор: admin изложил, на мой взгляд, идеальное решение для данного вопроса, ибо я реализовывал подобную схему также. к вышеперечисленным плюсам можно добавить еще работы с корзиной и заказами, там вам менять ничего не придется, там будет именно тот товар "псевдовариации" с цветом размером и ценой который выбрал клиент, а это минус кастом
и что немаловажно, было уже озвучено, но я повторюсь, это загрузка из 1С.