Алексей

Алексей

Был в сети 11 июля 2019, 10:26
Заказы не принимаю
Собираюсь реализовать расчет срока доставки в карточке товара. Название населённого пункта я получаю по geoAPI. Судя по документации, получается, что мне нужно самостоятельно хранить в БД соответствие названий населённых пунктов и их id. Правильно я понимаю?
Я использую msProducts, но кастомную таблицу с остатками. Исходя из того, что при вызове фильтра нужно использовать код таблицы, непонятно что туда передавать, когда таблица кастомная. У неё нет кода. Скорее все туда можно передавать любое значение, а таблицу задавать внутри методов.

По ссылке неполный пример. Там реализовано 2 метода из трёх. Если мой фильтр отличается только способом получения значений, я могу определить только метод getMyFilterValues. А для сборки и фильтрации будут использованы buildDefaultFilter и filterDefault. Верно?

К сожалению, пока нет компонента остатков под рукой, поэтому не могу проверить свои гипотезы.
Ок, 1С вычеркиваем. Остаются менее популярные системы учета, которые распространены среди небольших магазинов. Они умеют пробрасывать оффлайн-заказы через API.
на самом деле у нас есть пара других кейсов, когда на сайте вообще цены и остатки по сути не хранятся.
Обычно такие решения поставляются как веб-сервисы под ключ без доступа к коду. Поставщики разрабатывают такие сервисы-сайты для партнеров по системе «дропшиппинг». На чём написаны ваши сайты с подобной архитектурой?
Самое интересное, что может быть реализовано в реальном времени — это реалтайм синхронизация. С 1С, с моим складом, с amoCRM(если речь об услугах). Насколько мне известно, даже у битрикса, который имеет монополию в сфере инструментов онлайн-продаж на PHP и в то же время является разработчиком инфраструктуры 1С, решения по синхронизации со складом далеки от реалтайма, по сути они компромиссные. Если такая немагазинная по своей природе CMS как MODX вместе с минишопом сделает серьёзный рывок в области инструментов онлайн торговли. MODX на сегодня является самым гибким для SEO коробочным решением, но нераскрученный бренд и, возможно, отсутствие плюшек, как вышеуказанная мной, мешают движку занять свою нишу в этой категории
Спасибо за ответ. Я уже почти всё понял экспериментальным путем. Тем не менее ваша ссылка будет для меня очень полезна.

В данный момент меня интересуют 2 вопроса.

1. Какое имя таблицы использовать при вызове фильтра, если фильтр работает с таблицей стороннего компонента?

2. Я собираюсь фильтровать товары по остаткам конкретной опции. Не станет ли система внутреннего кеширования помехой для отображения актуальной информации в режиме реального времени. Если станет, то как с этим бороться
Спасибо за ответ. По вашей ссылке приведён пример организации остатков для обычных товаров. Если товар имеет модификации, созданные, например, с помощью дополнения msProductRemains, то остатки будут храниться в отдельной таблице или в таблице MIGX. Будет ли mSearch2 работать с такими данными?
А причем здесь переключение контекстов? Основные разделы сайта региононезависимы. Мне нужно, находясь в контексте web, правильно ставить ссылки на нужный региональный раздел, расположенный на отдельном контексте, и подтягивать подтягивать региональные блоки конкретного региона.
Спасибо за ответ! Регион итак хранится в куках, но когда кука ещё не выставлена, чтобы избежать многократного определения региона и выставления кук, вынес эту проверку в плагин. В итоге мне помог ваш вариант с плейсхолдером:
В плагине:
$key = $modx->setPlaceholder('region_key', $key);
В сниппете:
$key = $modx->getPlaceholder('region_key');
Стоп. Чанк не подходит для хранения информации о пользователе, при условии, что интерфейс многопользовательский. Нужен какой-то объект, который будет доступен из сниппета, в который можно положить context_key. Есть такое в MODX?
Как я понимаю, есть проблема с использованием общих шаблонов во всех контекстах и получении сущностей 2-го контекста из первого. Поправьте, если я не прав. Я писал, что использование контекстов мне не подходит. Если это так, то нужен альтернативный вариант