Для большей универсальности я бы ещё вынес всю работу по изменению html из метода status (js класс корзины)
в какой-нибудь отдельный метот, типа — applyHTMLChanges или лучше renderCart, так метод status будет чистым — отвечать только за получение данных актуальной корзины.
Сегодня был в работе магазин, в котором корзина и оформление — разные страницы.
Есть несколько компонентов, которые так или иначе пересчитывают корзину, ну и само собой все товары в ней.
Так вот в каждом таком компоненте авторы, в своем js, кто как реализует обновление данных корзины в html:
1) Кто-то циклом проходит и меняет в товарах цену и старую цену, а также результирующий блок
2) Кто-то целиком меняет весь кусок html кода корзины
Если в коробке miniShop2 будет универсальный метод получения актуальной корзины и обновляющий соответственно html на странице корзины, тогда в любом компоненте можно просто будет вызвать что-то типа
/**здесь любая логика по расчетам и.т.д*/
/**а в конце*/
miniShop2.Cart.status()
И всё сразу обновилось на странице на актуальные цифры.
Если понадобится что-то кастомное делать в чанке корзины, то поправить нужно будет только коробочный класс корзины (имею ввиду не исходники, а доработанную копию). То есть изменить только в одном месте.
Не придется лезть во все js других компонентов и везде менять реализацию обновления данных корзины.
Ну и ещё на ум пришел пример, если корзину делать на условном React, Vue, любом реактивном фреймворке, то как-то нужно получать стейт корзины из js, чтобы вьюха по стейту всё обновляла на странице.
Изучаю новый комплект js, и такой момент вижу
Мне одному кажется, что метод должен называться — sendRequest? Так как шлем «запрос» на сервер.
Или я тут что-то не улавливаю до конца?
Ещё момент, очень не хватает со стороны js метода запроса получения актуального состояния корзины,
чтобы прямо из консоли можно было вызвать так — miniShop2.Cart.status(); Без параметра, метод возвращал бы актуальную корзину, а с параметром как обычно отрабатывал. По аналогии как сейчас работает miniShop2.Order.getcost();
Прикольный компонент получился, хорошая альтернатива ContentBlocks от modmore.com
Единственное, что сразу бросилось в глаза, это при создании коллекции и выводе её в шаблоне через сниппет получается следующее неудобство:
Если в коллекции один элемент — возвращается объект
Если в коллекции более одного элемента возвращается массив
Если уж это коллекция то по идее должен всегда возвращаться массив, иначе нужно делать дополнительные проверки в шаблонах на то, что там вернул сниппет, массив или объект.
Это кстати уже не первый такой пакет в modstore, есть — eShopLogistic с таким же принципом.
Честно говоря такая практика не очень мне лично нравится, но хорошо, что хоть какие-то решения ещё появляются для MODX
Да с этой статьей уже знаком, и там в первом абзаце пишут, что EAV это про универсальность, а нам по сути это и нужно, угадать какая точно архитектура будет нужна конкретному магазину нереально, EAV как коробочное решение будет решать задачу универсально, пусть и не самым эффективным образом. А если продумать и заложить возможность полной замены реализации хранения и привязки опций — это даст ещё больше удобства, просто берешь отключаешь коробочное решение, и включаешь своё — но сомневаюсь, что многие этим будут пользоваться, моя статистика показывает, что там где уже есть EAV — мало кто пытается заменить на более производительное решение, так как хватает с головой коробочного. Но если речь про многомиллионные ассортименты и просто нереальное количество опций — то я думаю тут просто не падет выбор на MODX, как на платформу в целом.
Здорово, что ребята находят силы и время развивать продукт, спасибо им за это! Но чтобы компоненту хоть немного приблизиться к профильным решениям на рынке Ecommerce, его реально надо ставить на коммерческие рельсы и открывать обсуждение функционала в широкие массы, как и сбор средств на его развитие. Чтобы я хотел видеть в ecommerce решении для MODX из коробки:
1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.
2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)
3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.
4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)
5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.
Верно это не логгер ошибок, а как Вы написали красивый var_dump, для логирования ошибок в MODX хорошо бы прикрутить другой проект, так же от Spatie — называется ignition, он также с недавних пор framework agnostic, используется в Laravel по умолчанию.
Текущая версия buggregator поддерживает только локальную разработку, ну или если есть возможность поднять докер на сервере. А вот официальное приложение от Spatie позволяет добавлять и подключать сервера по SSH, но оно платное. Так что всё в руках разработчика, любые задачи решаемы)
Не, это то понятно) Я к тому что отдельно геокодер яндекса со 100% точностью определяет мой адрес, я поэтому и удивился, что компонент через яндекс не смог определить корректно геолокацию, а отдельно без проблем.
Заметил странное поведение компонента, версия последняя, каждая выгрузка из 1С создает по 3 сессии, хотя по логике должна быть всего 1, при первом запросе авторизации получается кука, устанавливается сессия и работает до конца обмена.
Только это не имеет большого смысла, так как с ресурсами можно работать в админке и без захода в сам ресурс, например через контекстное меню снять его с публикации, и тогда плагин не сработает, а даже если бы сработал, то в процессорах публикации/депубликации один фиг жестко прописан снос всего кэша.
Та же история с публикацией по расписанию.
Единственный вариант — это полностью переписывать реализацию класса кэш-менеджера и всех его методов.
Если хочешь прям для больших магазинов и чтобы удобно всем управлять и хранить, то почитай про архитектурную модель EAV, её используют почти все популярные движки интернет магазинов, начиная с OpenCart, Magento.
Хорошо бы этот механизм и в miniShop2 когда-то увидеть, то, что сейчас в нем есть уже на 500k товаров с парой десятков характеристик работает печально. Поэтому если нужен крупный магазин, я бы смотрел в сторону:
1) Aimeos (Laravel)
2) Bagisto (Laravel)
в какой-нибудь отдельный метот, типа — applyHTMLChanges или лучше renderCart, так метод status будет чистым — отвечать только за получение данных актуальной корзины.
Есть несколько компонентов, которые так или иначе пересчитывают корзину, ну и само собой все товары в ней.
Так вот в каждом таком компоненте авторы, в своем js, кто как реализует обновление данных корзины в html:
1) Кто-то циклом проходит и меняет в товарах цену и старую цену, а также результирующий блок
2) Кто-то целиком меняет весь кусок html кода корзины
Если в коробке miniShop2 будет универсальный метод получения актуальной корзины и обновляющий соответственно html на странице корзины, тогда в любом компоненте можно просто будет вызвать что-то типа
И всё сразу обновилось на странице на актуальные цифры.
Если понадобится что-то кастомное делать в чанке корзины, то поправить нужно будет только коробочный класс корзины (имею ввиду не исходники, а доработанную копию). То есть изменить только в одном месте.
Не придется лезть во все js других компонентов и везде менять реализацию обновления данных корзины.
Ну и ещё на ум пришел пример, если корзину делать на условном React, Vue, любом реактивном фреймворке, то как-то нужно получать стейт корзины из js, чтобы вьюха по стейту всё обновляла на странице.
Мне одному кажется, что метод должен называться — sendRequest? Так как шлем «запрос» на сервер.
Или я тут что-то не улавливаю до конца?
Ещё момент, очень не хватает со стороны js метода запроса получения актуального состояния корзины,
чтобы прямо из консоли можно было вызвать так — miniShop2.Cart.status(); Без параметра, метод возвращал бы актуальную корзину, а с параметром как обычно отрабатывал. По аналогии как сейчас работает miniShop2.Order.getcost();
Единственное, что сразу бросилось в глаза, это при создании коллекции и выводе её в шаблоне через сниппет получается следующее неудобство:
Если в коллекции один элемент — возвращается объект
Если в коллекции более одного элемента возвращается массив
Если уж это коллекция то по идее должен всегда возвращаться массив, иначе нужно делать дополнительные проверки в шаблонах на то, что там вернул сниппет, массив или объект.
Честно говоря такая практика не очень мне лично нравится, но хорошо, что хоть какие-то решения ещё появляются для MODX
1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.
2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)
3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.
4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)
5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.
Текущая версия buggregator поддерживает только локальную разработку, ну или если есть возможность поднять докер на сервере. А вот официальное приложение от Spatie позволяет добавлять и подключать сервера по SSH, но оно платное. Так что всё в руках разработчика, любые задачи решаемы)
чертовски удобно всё настраивать.
github.com/modx-pro/miniShop2/issues/627
Та же история с публикацией по расписанию.
Единственный вариант — это полностью переписывать реализацию класса кэш-менеджера и всех его методов.
Хорошо бы этот механизм и в miniShop2 когда-то увидеть, то, что сейчас в нем есть уже на 500k товаров с парой десятков характеристик работает печально. Поэтому если нужен крупный магазин, я бы смотрел в сторону:
1) Aimeos (Laravel)
2) Bagisto (Laravel)