31 мая 2011 в 22:53
Хочу создать интернет магазин, ну не просто так магазинчик. А нормальный хороший магазин.
Очень нравится вот этот магазин http://magazin61.ru/
Трудностей и сложностей не вижу. Но вот у меня стоит один вопрос по реализации. Может кто посоветует что.
Суть вопроса.
У каждой категории товара очень много своих индивидуальных полей. Вот если открыть http://magazin61.ru/household/tvanddvd/tvled/ и нажать кнопку "расширенный фильтр" у фильтра, то будет видно все поля по которым можно делать поиск. и так можно тыкать каждую категорию все уникально и все свое вот допустим холодильники. http://magazin61.ru/household/kitchenappliances/41/
Теперь вопрос как это можно реализовать, и как будет правильно. Первый ответ и пока единственный в голове это создавать под каждый товар свой класс и свои поля. Но меня пугает что у меня будет 50-100 типов материала типа: ТВ, холодильники, блендеры, утюги....... под каждый материал свой ноде.тпл, и огромное количество вьювсов что бы создать столько фильтров. Да и мне кажется ну рухнет у меня это все от такого количество типов материала?
Помогите, может я вообще не туда смотрю 
П.С. спасибо.
Комментарии
необязательно каждому типу товара делать свой шаблон ноды,
карточки (страницы) разных товаров более-менее унифицированы
попробуйте поэксперементировать:
- склонируйте product в какой-нибудь myproduct
- насоздавайте разным типам товара разных cck-полей, некоторые из которых пересекаются (потребляемая мощность, например)
- сгруппируйте эти поля
стандартный шаблон uc node-product.tpl.php будет рендерить ноды продуктов более-менее прилично, одним css можно неплохо причесать страницу
меня в этой ситуации угнетает несколько иное:
набор характеристик (полей) привязан к определенным типам товара (материала), которые, в свою очередь, привязываются к разным разделам каталога - очевидно, таксномией.
т.е. нода типа "mwave_oven" должна быть привязана к термину таксономии "Микроволновые печи", чтобы товар был в нужном разделе катклога с нужными полями-характеристиками
При создании/тестировании магазина с этим проблем возникать не должно, в реальном же магазине, с большим кол-вом товарных позиций контентом наверняка будет заниматься девачко с маникюром, что чревато несовпадением типа материала и его положением в каталоге.
100% в разделе "Утюги" будут товары с характеристикой "мощность всасывания" - от пылесосов.
Надо задумываться на предмет "защиты от дурака" при создании/правке товаров и устривать проверку на соответствие типов материала терминам таксономии из словаря "Каталог"
по представлениям - имхо, их кол-во можно тоже сократить, воспользовавшись стилем строк "Материал" и подшаманив шаблоны views-view-unformatted--имя_представлния.tpl.php и views-view-row-node--имя_представлния.tpl.php
А есть модуль который может одно cck поле разместить в нескольких типах материала?
а одно и то же поле может использоваться в разных типах материала, безо всяких модулей
Ого... тут либо вы немного запутались в вопросе. Либо я пойму что я.....
Как мне привязать одно поле к разным типам?
в одном из типов материала создаете поле, в остальных - при добавлении выбираете существующее
Мда.... спасибо большое. Век живи, век учись.
Они получаются связанные? при изменение одного меняется другое?
при изменении настроек поля в одном типе материала, они меняются в остальных типах материала, где присутствует это поле
А как по вашему мнению. Что из себя будет представлять друпал с 10000 товаров 50 типов материалов ну и даже если по минимуму пытаться урезать набор полей для фильтра, на вскидку 300 различных полей для этих 50 материалов?
А у вас есть опыт работы с Битриксом? так как много подобных магазинов построены на нем. Я просто не думаю что у Битрикса будет стоять задача легче чем у Друпала создать 50 типов материала и 300 полей. Я ошибаюсь?
Используйте не типы, а атпибуты в уберкарте например
Не понял... Как мне могут тут атрибуты вообще помочь? Атрибуты будут использоваться, но больше по своему назначению. Цвет и прочее...
Если правильно скомбинировать типы, атрибуты и таксономию - все будет в порядке.
Можно попробовать модуль Conditional Fields. В данном случае думаю будет в самый раз - в зависимости от выбора, например, типа товара для редактирования откроются определённые поля.
Тип материала будет один - товар. А views или дисплеев views будет столько, сколько типов товаров.
неее у меня есть один магазин на кондишен филд. больше не хочу... и уже пожалел что сделал не разными типа а кондишеном.
У меня получилась вот такая кака
она очень трудна в дальнейшем развитии, крыша едет, путаешься...
Есть у кого еще идеи по мимо создания 50 типов материала и 300 полей?
А вот еще вопрос. Что страшнее большая таксономия или огромное количество полей?
Я смотрю базу сайта и понимаю что если отдать большую часть таксономии то таблица term_node сильно разрастется и выборки будут проблематичны. А вот у ССК таблицы более грамотно, и будет расти не размер одной таблицы, а количество таблиц в базе.
Я правильно думаю?
Уже спрашивал
я в упор не вижу там 300 полей, с учетом того, что многие из них пересекутся так или иначе
У меня тут есть немного другой ответ
Andruxa что вы думаете о таком мнение?
Мы насчитали порядка 280, это только на старте. Будут расти позиции будут расти поля. Там только у рубрики "Комплектующие для ПК" полей будет больше сотни.
Имхо, так или иначе придется платить производительностью
Я склоняюсь к полям по причине того, что поле представляет собой пару заголовок-значение, причем значения могут быть разных типов
таксономия с этой точки зрения - это поле со значением bool (есть/нет), для характеристик товаров этого не всегда достаточно
Спасибо
специально залез на Я.Маркет и прайс.ру
у первого - 14 подкатегорий, у второго - 17, включая "Комплектующие для промышленных компьютеров"
т.е. вы предполагаете, что в каждой подкатегории (типе товара) у вас будет по 5-7 уникальных характеристик/полей?
я думаю, вы строите структуру каталога не в ту сторону, и вот почему:
задача всех этих полей - дать возможность пользователю легко подобрать товар по нескольким имеющимся у него в голове критериям
ключевое слово - легко
имхо, многие поля, которые вы собираетесь создать - с точки зрения пользователя лишние
их можно перенести в описание товара, как дополнительную информацию о товаре, уменьшив тем самым нагрузку на базу.
имхо лучше сделать модуль типа table field, только с двумя колонками, и индивидуальными настройками полей по умолчанию для каждого типа, хранить инфу в серелизованном массиве
такая структура также даст возможность реализовать сравнение товаров, для полей по которым нужно фильтровать пользоваться таксономией