Николай Савин
С нами с 01 января 1970; Место в рейтинге пользователей: #2Сегодня в 13:13
Если только после майских праздников можно будет сделать для 2.x. Попробую.
mxDadata — интеграция DaData (Suggest, Clean, Party) с MODX 3 и MiniShop3 2
Сегодня в 11:51
Я так же все локально разрабатывал и тестировал и все ок было
msp3YooKassa - Интеграция с платежной системой ЮKassa 7
Вчера в 15:27
Я потому и задал вопрос о том как реализовано в Minishop3?
Новости MiniShop3, mSearch, mFilter 7
22 апреля 2026, 06:21
Мне лично документация вообще не понятна :-). Все просто в доке, но вот вопрос, что за канал создается через ваш бот? Это наш канал или ваш? В доке ма...
[MAX bot] отправляем сообщение в бот MAX на изи 8
22 апреля 2026, 00:22
Оказалось, что Localizator конфликтовал с плагином prettyTags. Ошибки в журнале с этим не связаны.
Localizator 1.0.9 и 1.1.0 8
21 апреля 2026, 19:25
Всё же разобрался.
Браузеры игнорируют CSS-файлы, если сервер отправляет неправильный MIME-тип. Например, вместо text/css может возвращаться text/ht...
pdoTools и sql_mode=only_full_group_by - ошибки при работе PdoPage 3
18 апреля 2026, 15:34
открыл, не знаю, почему он закрыт оказался) но, стоит учесть, что код там очень старый
msProductKits - удобное управление товарами-комплектами (наборами товаров) 31
15 апреля 2026, 13:43
Несколько корзин на странице это исключительно визуализация. miniShop2 только одна корзина. Из коробки показать её можно всего двумя способами, мой па...
[MsAltCart 1.0.7] Теперь с документацией. 3
Спасибо за ваше критическое замечание. Мы обязательно его рассмотрим в отведенные сроки.
Прошу заметить, что несмотря на архитектурно-инфраструктурные пробелы, приложение все равно становится лучше и современнее. Некоторые xpdo модели, за счет выноса логики в отдельный слой похудели в разы. А эту самую логику в отдельных слоях (как бы они не назывались) теперь можно подменять через DI
Путь такой.
1. Заполняю модальное окно данными, жму сохранить
2. Контроллер создает миграцию (Alter table Add column) и сразу же ее запускает. Вот на этом моменте используется phinx
3. Делаем запись в таблицу extra_fields.
4. Ну и где то за кадром происходит слияние нативной карты модели msProductData и новых дополнительных полей.
Примерно такая же схема при удалении поля.
Жму кнопку удалить, создается миграция на удаление колонки из таблицы. Она запускается сразу же, после создания.
Почему схема такая, а не предложенный тобой вариант.
Ну для начала поля из extra_field можно отключать. Колонка физически остается в базе данных, но перестает попадать в карту msProductData. Это может быть полезным.
Кроме того физически перегенерированную карту msProductData обновление минишопа просто перезапишет. Можно конечно это разрулить на уровне резолверов, но зачем? Предложенная схема вроде справляется с задачей
Так MS3 целиком предназначен для MODX3. Я не занимаюсь развитием платформы для MODX2.
Тут ничего не изменилось. Поля товара как хранились в ms2_products так и хранятся.
А как ты их между собой связал? Это же разные сущности.
Если вопрос о том, как новые поля попадут в xpdo модель — то там наш старый привычный еще из ms2 способ, который на лету обновляет $meta['map']
Цепочка загрузки:
- 1. OnMODXInit → $ms3->loadMap()
- 2. MiniShop3::loadMap() → $this->extraFields->loadMap()
- 3. ExtraFields::loadMap() → загружает ms3_extra_fields (active=1)
- 4. ExtraFields::getFieldInfo() → формирует метаданные
- 5. ExtraFields::addFieldToMap() → МОДИФИЦИРУЕТ $modx->map[$class] ← ВОТ ГДЕ МАГИЯ!
- 6. xPDO видит новые поля как нативные
Тут я бы разделил ответ1. Репозиторий — это паттерн. Нет четких правил по его использованию или обязательств его использовать. Так что каждый волен делать так, как видит. Вот Laravel до пятой версии вообще всю логику внутри моделей тягал и ничего.
2. На практике, насколько я видел как пишут другие, сервис и репозиторий по сути своей одно и тоже. Их задача разгрузить контроллер, вынести логику в отдельный контейнер.
Я вижу так.
Контроллер принимает запрос от API и отдает ответ. На этом все. Его зона ответственности Request-Магия-Response.
Репозиторий и\или Service — логика. Здесь идет разбор запроса, обращения к DB, построение ответа. Задача сервиса — подготовить ответ согласно запроса.
Model — исключительно работа с базой. Ее задача сходит в базу и выполнить поставленную задачу.
Пример вызова
Для начала прекращайте смешивать синтаксис — у вас проблемы из-за этого, в том числе. Напишите все нормально либо в fenom, либо в MODX синтаксисе. Это разные технологии, они по разному устроены и работают.
@Aleksandr Huz на этот раз тебя не забыли.
DeepSeek конечно отсыпал знатно и всему сообществу, и мне за минишоп и отдельным товарищам
Попробуй писать msProductOption.flat_area вместо простого flat_area
Попробуй вот такой конфиг
Тогда PHP внутри пофиг откуда загружать код.
Соответственно автор может только своевременно обновлять либу, и никак не в силах предсказывать ее дальнейшее развитие