Это да. Особенно когда свободного времени мало. Но я вижу причины для чего так срочно нужно выпустить решение с костылями. В крайнем, лучше сделать копи/паст по всем правилам современной разработки.
Потому что ты запрашиваешь объекты. И тебе выводятся поля из объекта.
Для понимания. Если ты создашь новый пустой объект и выведешь его
$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>";
}
В этом случае получишь то, что запрашивал. И памяти меньше кушает.
Интересная статья для размышления. Не хватает четвертого варианта, который описал Василий выше и который использую я при разработке RESTful API дополнения.
Первые два варианта из разряда «забить гвоздь телефоном». Результат маленький и большие накладные расходы.
Третий вариант — это взять маленький молоточек. Чтобы забить средние и большие гвозди придётся сильно попотеть.
Цикл статей, имхо, нужен только для понимания, что встроенные средства MODX мало пригодны. Только для исключительно простых целей. Как по мне, даже JSON:API спецификация с его include, fields, filter и sort неудобна. Мне как разработчику было бы проще послать POST запрос, в котором описать как положено select, where, limit и т.п. Да, это уже не REST, но возможностей гораздо больше.
Во-первых, это не готовое API, а инструкция по его созданию.
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.
Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)
Для комментариев используется набор параметров Comment.
joxi.ru/nAybzZ6fgRJEor
Так вы работаете с тикетами? Или только с Jevix?
Просто ты ответил немного неопределённо —
То ли за третий, то ли за второй.
П.С. Надо было сделать четыре комментария с каждым вариантом и за них голосовать. Эмулировать опрос. Стормозил чутка.
Для понимания. Если ты создашь новый пустой объект и выведешь его
то тоже получишь все поля, но пустые.
В твоём случае, ты инициализируешь указанные в select поля объектов данными из базы. Остальные поля — так называемые lazy. Они инициализируются из кэша. Если кэша нет, то делается запрос в базу и сохраняется в кэш.
Если нужно получить массив данных (что предпочтительней), то лучше делать так
В этом случае получишь то, что запрашивал. И памяти меньше кушает.
Какое решение лучше?
Интересная статья для размышления. Не хватает четвертого варианта, который описал Василий выше и который использую я при разработке RESTful API дополнения.
Первые два варианта из разряда «забить гвоздь телефоном». Результат маленький и большие накладные расходы.
Третий вариант — это взять маленький молоточек. Чтобы забить средние и большие гвозди придётся сильно попотеть.
Цикл статей, имхо, нужен только для понимания, что встроенные средства MODX мало пригодны. Только для исключительно простых целей. Как по мне, даже JSON:API спецификация с его include, fields, filter и sort неудобна. Мне как разработчику было бы проще послать POST запрос, в котором описать как положено select, where, limit и т.п. Да, это уже не REST, но возможностей гораздо больше.
Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.
Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)