Привет. Хочу представить вам новый движок интернет-магазина с открытым кодом. Недавно мы сделали альфа-релиз, и нам есть что показать.
Почему мы начали этот проект? Это главный вопрос.
В мире не так много движков с открытым кодом, которые ориентированы на создание интернет-магазинов. Мы много лет занимались разработкой интернет-магазинов на других платформах и пришли к пониманию того, что в современной форме платформы полны сложных манипуляций для производства простых повседневных вещей. Чтобы выполнить простое действие, нужно прыгать по меню. Это значительно снижает продуктивность работы менеджера магазина и увеличивает вероятность ошибок.
Мы решили, что эти недостатки превратятся в преимущества на нашей платформе. Мы изначально много времени уделяем эргономике, сохраняя при этом базовый функционал. Многие решения мы впервые делаем в интернет-магазинах с открытым исходным кодом. И это здорово. Ведь теперь можно просто управлять сложными вещами. Добавление товара становится проще. Скидками легко управлять. Характеристики товаров создавать намного проще. Многие привычные действия значительно упрощены, и при этом их функциональность даже больше, чем мы привыкли видеть.
И мы намерены и дальше двигаться вперед. Мы верим, что наше решение пойдет на пользу людям. Мы прилагаем для этого много усилий. 1 января 2021 года мы выпустили нашу первую альфа-версию. Вы можете посмотреть демонстрацию на нашем сайте. И да, раз я пишу здесь на русском, то я всегда на нем и отвечу, так как это мой родной язык.
Проект на GitHub - https://github.com/musicman3/eMarket
Техподдержка и демо - http://emarketforum.com
P.S. По просьбе трудящихся прикрепляю данные, которые ведут сразу на демо страницы.
ДЕМО АДМИНИСТРАТИВНОЙ ПАНЕЛИ
http://demo.emarketforum.com/controller/admin/
[email protected]
pass: 1234567
ДЕМО КАТАЛОГА
http://demo.emarketforum.com/
[email protected]
pass: 1234567
Пока не понятно для кого продукт.
Если для разработчиков, которые хотят сделать свой быстрый и сильно кастомизируемый онлайн-магазин, то тогда непонятен отказ от фреймворков. Для того же Laravel/Symphony/Yii 2 существует большое количество модулей и это, наверное, было бы неплохим решением для тех, кто хочет сделать кастомный магазин на хорошо знакомом фреймворке и ему нужна какая-то основа. А так встает вопрос - зачем делать магазин для клиента на непонятном движке, когда можно взять хорошо знакомый фреймворк и сделать все на нем, получив поддержку от большого сообщества?
Для частных предпринимателей и небольших бизнесов ? Тоже нет, слишком сложно, мало готовых модулей и тем по сравнению с лидерами рынка. Дизайн и ux админки (по первому взгляду) не сильно лучше того же Wordpress или Битрикса.
Я не эксперт, но похоже для разработчиков данный продукт не выход:
а) он строго завязан на определенных решениях, например в плане БД - MySQL;
б) Не понятно как расширять приложение, то есть делать модули;
Поправка: сами модули есть, но похоже что они либо изолированы(функционал не связан с основным приложением), либо модифицируют код приложения(а не расширяют, например с помощью "Событий")
в) Из пункта №2 выходит отсутствие обратной совместимости.
Очень много вопросов к архитектуре. Открыл файл, к примеру: https://github.com/musicman3/eMarket/blob/master/controller/catalog/pages/address_book/index.php
1) В первую очередь: спагетти-код.
2) Не понятна какая парадигма программирования. Весь код довольно смешан: приём данных, валидация, обработка, определение роли и т.д.
3) Сложности в написания тестов из-за №1, №2. При росте приложения, что свойственно для этой тематики, будет сложно тестировать. Всё это мультиплицирует энтропию ПО.
4) Насколько вижу, нет важных компонентов: работа с кэшированием, EAV, ЧПУ.
5) Мелочь, но некоторые конструкции можно было бы сократить для улучшения читаемости. Например: https://pastebin.com/kvFRGYrw
Но очень хорошо, что стараются. Возможно, сузят тематику до какой-то ниши, где мало популярных решений и будут развиваться, улучшая архитектуру.
Прежде всего спасибо что уделили время и ознакомились более детально. Ваши замечания по улучшению читаемости интересны. Это конечно дело привычки написания кода, но в целом мне нравится ваш подход на этом конкретном примере.
По поводу модулей. Все они находятся в папке modules и они полностью отвязаны от шаблона. Все в одной папке включая классы, языки и т.п. Кидаете новые модули и они тут же отображаются в админке и ждут активации. Можно взять для примера модуль доставки а на нем понятно как писать модули. Кроме того была проделана большая работа чтобы отвязать модули скидок от движка и сделать полностью независимыми как модули оплаты или доставки. Сейчас все скидывается по интерфейсам в блок расчета. Благодаря этому удалось сделать их независимыми.
БД на данный момент MySQL через PDO.
По поводу спагетти кода это немного не так. Дело в том что в контроллере в основном короткие обработчики, а все классы собраны в Model->eMarket и Model->Vendor.
Сложностей с тестами не будет, когда структуру немного разберете.
ЧПУ и др. пока не вводилось, так как все таки еще Альфа 1.0.
Структура MVC+L.
В любом случае работы еще много впереди, и конструктивная критика всегда полезна.
Подскажите, пожалуйста, файл по ссылке из комментария выше - это в вашей парадигме M, V, C или L?
Model-View-Controller + Language
Всё вместе? Вы понимаете, что Model, View и Controller в парадигме MVC должны находиться в разных файлах, а не быть свалены в одну кучу?
парадигма MVC + L и означает что все разделено. Не понимаю Вашего вопроса. У нас все разделеною
Я просто смотрю в файл https://github.com/musicman3/eMarket/blob/master/controller/catalog/pages/address_book/index.php и вижу:
1. Обработку пост-параметров - это Controller?
2. SQL - это Model?
3. Вывод сообщения об успехе - это View?
4. i18n - это View?
Это не MVC, это винегрет.
Тссс... Не расстраивай дядьку.
Дядька новую концепцию выдумал — Model-View-Controller + Language, имей уважение.
1. - Класс для пост-обработки ( точнее для фильтрации inPOST) находится в Model. Сам контроллер используется для обработки простых действий.
2. Для SQL отдельно папку создать? Как бы там все и должно быть. Это по вкусу.
3. Вывод сообщений об успехе и должен быть в шаблоне, но сама обработка идет через класс из Model.
4. Вывод данных только в View и должен быть. Но обработка через lang-функцию из Model
Почему вы думаете, что сложностями с тестами не будет, если у вас в проекте нет ни одного теста?
нет тестов - нет проблем с тестами)
по движку
бегло посмотрел: очередной велосипед, с не особо дружелюбным комьюнити (судя по манере общения мейнтейнера в этом посте)
пока не вижу никаких фич, которые могли бы заставить хотя бы подумать о переходе
На закрывающим теге php можно уже было закрыть это безумие и больше не открывать. Годы прогресса языка PHP проплыли мимо этой команды разработчиков.