Сергей Шлоков

Сергей Шлоков

Был в сети 06 ноября 2025, 19:54
Заказы не принимаю
Написать Отправить деньги
А под своими процессорами ты имеешь ввиду свои, но наследники modProcessor, или вообще свой механизм?
Просто ты ответил немного неопределённо —
Только 3й вариант, только свои процессоры.
То ли за третий, то ли за второй.

П.С. Надо было сделать четыре комментария с каждым вариантом и за них голосовать. Эмулировать опрос. Стормозил чутка.
Для разработчиков Процессоры в RESTful API: использовать нельзя выбросить 17
Боюсь большой объем работы просто застопорит все.
Это да. Особенно когда свободного времени мало. Но я вижу причины для чего так срочно нужно выпустить решение с костылями. В крайнем, лучше сделать копи/паст по всем правилам современной разработки.
Для разработчиков Процессоры в RESTful API: использовать нельзя выбросить 17
Потому что ты запрашиваешь объекты. И тебе выводятся поля из объекта.

Для понимания. Если ты создашь новый пустой объект и выведешь его
$resource = new modResource(...);
$resource->toArray();
то тоже получишь все поля, но пустые.

В твоём случае, ты инициализируешь указанные в select поля объектов данными из базы. Остальные поля — так называемые lazy. Они инициализируются из кэша. Если кэша нет, то делается запрос в базу и сохраняется в кэш.
Если нужно получить массив данных (что предпочтительней), то лучше делать так
$resources = [];
if ($c->prepare() && $c->stmt->execute()) {
    $resources = $c->stmt->fetchAll(PDO::FETCH_ASSOC);
}
foreach($resources as $resource){
    echo "<pre>".print_r($resource, true)."</pre>";
}
В этом случае получишь то, что запрашивал. И памяти меньше кушает.
Вопросы Почему не срабатывает select на modResource? 2
Выскажу здесь своё никому не нужное мнение.

Интересная статья для размышления. Не хватает четвертого варианта, который описал Василий выше и который использую я при разработке RESTful API дополнения.
Первые два варианта из разряда «забить гвоздь телефоном». Результат маленький и большие накладные расходы.
Третий вариант — это взять маленький молоточек. Чтобы забить средние и большие гвозди придётся сильно попотеть.

Цикл статей, имхо, нужен только для понимания, что встроенные средства MODX мало пригодны. Только для исключительно простых целей. Как по мне, даже JSON:API спецификация с его include, fields, filter и sort неудобна. Мне как разработчику было бы проще послать POST запрос, в котором описать как положено select, where, limit и т.п. Да, это уже не REST, но возможностей гораздо больше.
Для разработчиков MODX и REST 5
Во-первых, это не готовое API, а инструкция по его созданию.
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.

Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)
Для разработчиков AdminRevolution. Быть или не быть? 148