e_v_medvedev

e_v_medvedev
Рейтинг
183
Регистрация
07.03.2013
ВладимирЯ:
Ну ты молодец! Они тут спорять о сложности той или иной платформы. а ты подкинул - первое что увидел когда хотел узнать стоимость:
Важной особенностью является то, что Melbis Shop 6 является многофункциональной платформой на базе которой создается интернет-магазин. Поэтому для настройки Вашего бизнес-процесса и формирования витрины магазина, Вам, скорее всего, потребуется обратиться к нашим партнерам - разработчикам готовых магазинов на базе Melbis Shop 6.

Melbis Shop 6 - это профессиональный продукт, как правило, его выбирают владельцы уже состоявшихся интернет-магазинов, а не впервые создаваемых.

Так ведь очевидно-же что примитивная неприкрытая реклама. Что вы хотите?

murd0c:
... причем, поскольку товары добавлялись из эксель – похожие предложения выводятся рядом (цвет и конструкция одинаковая, но размеры разные). Некоторые категории имеют 50+ страниц и их пролистать все до конца не каждый осилит.

Для начала возьмите движок с опциями или с настраиваемыми товарами типа Magento. Там можно задать один товар в котором объединить сходные товары с одной или двумя отличными опциями. Так вы сократите список выдачи в категориях и обойдете проблему отображения очень похожих товаров рядом.

_SP_:
Собственно я знаю, как оно сейчас обстоит дело.
В деталях разбираюсь во внутренней кухне итп.

Однако. Если предположить, что "движок" магазина направлен на продажи в интернете,
а не на ведение склада и отчетности, переписку, печать бланков итп (это всё делает локальная
система отделенная от него), то зачем в нём необходим сервер баз данных :) ?

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

Нет, больше я не храню заказы - они высылаются по email и обрабатываются локальной системой.
(на всякий случай копия хранится в виде файлов в дирректории с заказами)

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

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

Нет, мой магазин теперь не переписывается с пользователями - это дело рук менеджера,
либо опять-таки локальной системы.

Нет, теперь никто не заводит товар руками(и не косячит), он выгружается автоматом из той-самой локальной системы.

Нет, корзин я тоже больше не храню, для этого есть local-storage.

Ответ по-моему очевиден. Используют стандартную СУБД, чтобы не накручивать свою. Вы ведь по сути над файловой системой надстроите свою СУБД. Зачем? Не понятно. MySQL вообще-то тоже с файлами работает? Что вы нового придумали? Заменили двоичные файлы данных текстовыми (CSV или XML)?

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

пс. Здесь и надо как правильно, как привык потребитель этого сегмента.

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

humbert:
Ему не помешают, целесообразность интересует. Чтобы сделать магазин надо время выделить, деньги, а будет ли выхлоп именно с инета.

Так то будет, конечно, если интернетом заниматься, а не просто открыть сайт и забить на него.

Если в оффлайн магазине не выделять время и деньги, то там тоже выхлопа не будет. Какая разница - оффлайн или онлайн магазин. В обоих нужно торговать и делать это грамотно.

Igor_Mal:
Вот это я понимаю экспертная оценка! Посмотрел! А поработать с ним не пробовали? Главное преимущество Spree - не в коробочном функционале. А в возможности пилить любые расширения. И с ограничениями по функционалу я пока не сталкивался. Но я же не "посмотрел", а участвовал в реализации целого ряда проектов. Этого явно недостаточно.

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

Да, специально посмотрел этот Spree. Ни чего особенного. Функционально это примерно Sylius. До Мадженто точно не дотягивает. Фраймворк Райлс тоже не богат функционалом, по крайней мере по сравнению с ZF2.

Chukcha:

Что касается разработки под web - то не имеет значения время разработки если знаешь серверный язык, кстати, а почему бы и не extjs? То же не годится?

ExtJS это фрэймворк и ориентирован на клиентскую часть а не на серверную. Может вы имели ввиду NodeJS?

717u717:
Посоветйте cms для продажи электронных товаров, что бы можно было привязать оплату биткоинт, еще что бы можно было покупать у пользователей электронный товар?

Попробуйте Мадженто с этим модулем https://www.magentocommerce.com/magento-connect/bitpay-bitcoin-payment-method.html

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

Теперь по существу.
1. Приведенные данные по ядру платформ можно найти (о ужас!) в репозитории на GitHub.
2. Я оценивал функционал Spree. Он фактически безграничен, поскольку платформа легко кастомизируется. Отсюда простой вывод: кода меньше, функционала не меньше.
3. Все перечисленные мной магазины относятся не к Ruby, а к уровню развития рынков. И в том, что Spree пользуется спросом на западе, но не в России, я вижу лишнее подтверждение тому, что у нас пока очень мало заказчиков стремится к созданию высоконагруженных магазинов, готовых к созданию самых разнообразных расширений, неограниченному росту пользователей и ассортимента, а также к индивидуальному дизайну (это и есть премиум-сегмент).
4. Я работаю не только с Россией и Европой, но также и с Китаем, и с Штатами, и с Канадой, и с Эмиратами. Я понимаю, что мое мнение у вас не вызывает доверия, оно же откуда-то там высосано. Видимо приведенная мной статистика по рынкам вас тоже не убедила. Можете еще почитать рейтинги на www.datanyze.com. Или поискать рейтинг крупнейших интернет-магазинов в мире. Хотя, видимо, не стоит. Ведь там же наверняка окажется куча российских интернет-магазинов.

Судя по всему мы так и не дождемся когда вы начнете отвечать по существу.

Ваши слова относительно сомнительности ваши утверждений вы так и не опровергли. Вопросы вам задавал о доказательной базе не я один. Но вы ни кому так и не ответили.

Сказки о том, что функционал Spree, безграничен потому что движок кастомизируется - смехотворен, потому что вы видимо поалгаете, что движки на PHP вообще не кастомизируются.

В одно и постов, с которых началось наше обсуждение вы высказали абсурдную по сути мысль, что как только рынок eCommerce разовьется в России то Ruby просто ломанется в массы, а сейчас все сидят на PHP потому что рынок недоразвит (см. /ru/forum/comment/14834400) А теперь начинаете тут что-то накручивать в свое оправдание. О какой вы дискуссии по существу говорите. Вот вам дискуссия - вы высказали ошибочное и по сути неуважительное отношение к многим участникам этого форума и получили по заслугам. Так что осторожнее в выражениях в следующий раз.

Всего: 2095