Все нижеизложенное мое ИМХО.
Возможно все это существует, но я об этом просто не знаю. В частности, Magento копать не стал по причине исключительной тормознутости данного творения на моем скромном железе без допиливания конфигов и кеширования.
1.Поиск товара с подгрузкой в строку поиска вариантов, на основе введенных символов.
Сейчас начинаю копать elasticsearch - возможно с ним получится. СФинкс у меня на маке с кириллицей не подружился, а разбираться пока некогда.
2. Фильтр по параметрам. Они в принципе встречаются, но мне нравится мой вариант, хотя он и неклассический и избыточный.
У меня в таблице товаров есть поля кодов фильтров и значений фильтров. Коды целочисленные и индексные. При вставке сверяем категорию, название параметра и его значение. Если не встречалось - добавляем. Если встречалось - возвращаем код.
В итоге тратим время на вставке, но зато выборка идет без джойнов. Написано оно кривовастенько, но работает удобно.
3. Интеграция работы с семантическим ядром. Тут обычно вся работа на площадках, которые предоставляют услуги по продвижению, а как бы организовать импорт задач для продвижения и дать интерфейс посмотреть где целевая страница для фразы, как она в статистике себя ведет итп.
Готов поучаствовать в работе, но реальная возможность появится примерно с августа. До этого - со временем будет очень туго, но буду стараться какое-то время найти.
Опыта опенсорс разработки к сожалению нет. Работаю в одиночку над проектами не девелоперской а обычной компании. (Торговля, туризм)
Сбор требований
Модератор: core team
-
alexander.petrusha
- Новенький
- Сообщения: 1
- Зарегистрирован: Пн май 26, 2014 10:42 am
не разрабатывал интернет-магазины и не являюсь его владельцем)
но есть некоторое представление, возможно и ошибочное)
так вот:
1) должен быть модуль приема платежей. По умолчанию прием платежей через webmoney и yandex money. так же должны быть возможность писать компоненты для приема платежей через агрегаторов Robokassa и др. То есть нужен будет какой то абстактный класс с описанием всех возможных методов и на основе этого класса писать другие)
2) модуль доставки. Так же как и модуль платежей: какие то базовые варианты доставки + класс помогающий написать свой компонент доствки.
но есть некоторое представление, возможно и ошибочное)
так вот:
1) должен быть модуль приема платежей. По умолчанию прием платежей через webmoney и yandex money. так же должны быть возможность писать компоненты для приема платежей через агрегаторов Robokassa и др. То есть нужен будет какой то абстактный класс с описанием всех возможных методов и на основе этого класса писать другие)
2) модуль доставки. Так же как и модуль платежей: какие то базовые варианты доставки + класс помогающий написать свой компонент доствки.
Nested Sets каталог.
Чтобы можно было эффективно получать товары из любой категории и её подкатегорий.
Чтобы можно было эффективно получать товары из любой категории и её подкатегорий.
Последний раз редактировалось turakod Вт авг 19, 2014 2:54 pm, всего редактировалось 1 раз.
Re: Сбор требований
В принципе функционалы CMS интернет-магазинов схожи. Мне стандартного функционала OpenCart + модули хватает на 80-90%.
Единственное, на чём хотел заострить ваше внимание, так это на продвинутом функционале по работе с опциями товаров.
Большинство таких движков рассматривают опции товара как модификатор цены (и то не у всех есть модификаторы *, +%, -% и т.д.), а не как новое состояние товара.
К примеру, товар одежда с размерами. Допустим разные размеры одного товара стоят одинаково (у движков это модификатор +0). Но я хочу иметь возможность заказать в карточке товара сразу несколько разных размеров с разным количеством. И в заказ в итоге должно попасть несколько позиций одного товара с разными размерами и количеством. Можно конечно использовать модификатор +100%, но тогда в заказ попадет одна позиция товара с несколькими опциями с количеством у каждой опции. Я считаю что одежда разных размеров это разный товар и клиент должен четко видеть какой одежды какого размера и какого количества он заказал. Но не создавать же кучу товаров (клонов исходного товара) с разным размером. Неудобство как для админа, так и для клиента.
Далее, обязательно пересчет итоговой цены в карточке товара (AJAX или что уж там решите). Клиент должен знать какую сумму он добавляет в заказ нажимая на кнопку.
Далее, обязательно опции с количеством (опционально, писал о них выше). Соответственно количество товара пропадает.
Далее, опции в виде слайдера с мин-макс значениями и шагом.
Далее, взаимодействие модификаторов цены между собой (например, модификатор опции у товара *, но между собой разные опции могут складываться). Не понятно? Сорри) Утрированный пример, я продаю сыр за 100 рублей, режу его разными кусками по 100, 300, 500 и 1000 грамм. Это опция у товара в виде чекбокса да еще и с количеством. Опция умножает цену (цена за кг) на 0.1, 0.3, 0.5, и 1 (сделано чтобы было легко менять цену). Я (как клиент) хочу заказать 2 куска по 100 и 3 куска по 500. Сколько должно получиться? (2 * 0.1 + 3 * 0.5) * 100 = 170 рублей. Т.е. опции между собой складываются хотя модификатор умножения. (пример дурацкий, т.к. тут нужно использовать слайдер с шагом, но может я не хочу по 200 грамм резать =)).
Т.е. получается целый конструктор опций. Если его грамотно продумать, пусть даже в ущерб удобности в админке (т.к. это редко меняется и делается это людьми понимающими), то будет просто супер.
Вообще в основном все танцы с бубном идут именно вокруг опций. Так, неплохо было бы иметь зависимые опции (например, ну нет у меня красной (это опция) майки именно 52 размера (тоже опция)).
И в обязательном порядке очень удобно-настраиваемый фильтр по товарам (с возможностью на главной).
Насчет админки хотелось бы видеть массовое редактирование товаров с фильтром и всеми вытекающими. =)
Единственное, на чём хотел заострить ваше внимание, так это на продвинутом функционале по работе с опциями товаров.
Большинство таких движков рассматривают опции товара как модификатор цены (и то не у всех есть модификаторы *, +%, -% и т.д.), а не как новое состояние товара.
К примеру, товар одежда с размерами. Допустим разные размеры одного товара стоят одинаково (у движков это модификатор +0). Но я хочу иметь возможность заказать в карточке товара сразу несколько разных размеров с разным количеством. И в заказ в итоге должно попасть несколько позиций одного товара с разными размерами и количеством. Можно конечно использовать модификатор +100%, но тогда в заказ попадет одна позиция товара с несколькими опциями с количеством у каждой опции. Я считаю что одежда разных размеров это разный товар и клиент должен четко видеть какой одежды какого размера и какого количества он заказал. Но не создавать же кучу товаров (клонов исходного товара) с разным размером. Неудобство как для админа, так и для клиента.
Далее, обязательно пересчет итоговой цены в карточке товара (AJAX или что уж там решите). Клиент должен знать какую сумму он добавляет в заказ нажимая на кнопку.
Далее, обязательно опции с количеством (опционально, писал о них выше). Соответственно количество товара пропадает.
Далее, опции в виде слайдера с мин-макс значениями и шагом.
Далее, взаимодействие модификаторов цены между собой (например, модификатор опции у товара *, но между собой разные опции могут складываться). Не понятно? Сорри) Утрированный пример, я продаю сыр за 100 рублей, режу его разными кусками по 100, 300, 500 и 1000 грамм. Это опция у товара в виде чекбокса да еще и с количеством. Опция умножает цену (цена за кг) на 0.1, 0.3, 0.5, и 1 (сделано чтобы было легко менять цену). Я (как клиент) хочу заказать 2 куска по 100 и 3 куска по 500. Сколько должно получиться? (2 * 0.1 + 3 * 0.5) * 100 = 170 рублей. Т.е. опции между собой складываются хотя модификатор умножения. (пример дурацкий, т.к. тут нужно использовать слайдер с шагом, но может я не хочу по 200 грамм резать =)).
Т.е. получается целый конструктор опций. Если его грамотно продумать, пусть даже в ущерб удобности в админке (т.к. это редко меняется и делается это людьми понимающими), то будет просто супер.
Вообще в основном все танцы с бубном идут именно вокруг опций. Так, неплохо было бы иметь зависимые опции (например, ну нет у меня красной (это опция) майки именно 52 размера (тоже опция)).
И в обязательном порядке очень удобно-настраиваемый фильтр по товарам (с возможностью на главной).
Насчет админки хотелось бы видеть массовое редактирование товаров с фильтром и всеми вытекающими. =)
Возможность отображения вариантов товара таблицей.
Возможность отображения вариантов товара таблицей.
Вернуться в «Интернет-магазин (yupe 2.x)»
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей