В общем было бы замечательно если бы modx из коробки поддерживал бы еще парочку шаблонизаторов на выбор) Так он сейчас как бы и поддерживает (основное новшество версии 2.2.7, анонсированной на 9 апреля). Теперь можно переопределить системную настройку, и $modx->getParser() будет подтягивать ваш собственный парсер. Но я не уверен, что там все идеально (сужу по логике Смарти). Шаблонизатор компиллирует свои шаблоны, а не просто парсит какой-то код. Это включает подгрузку функций всяких и т.п. А если у нас в чанке код, я не могу сказать точно по поводу того, как Смарти будет кушать этот код. Есть ли возможность скармливать ему контент. Очень сомневаюсь, так как он подавится первой же фигурной скобкой. Может Twig лучше себя ведет? К любом случае, я считаю, что они должны сделать поддержку php-кода в шаблонах (на подобии того, как это у меня сделано в phpTemplates). В таком случае я четко знаю, что я выполню чистый php, пропишу там логику, и всегда буду уверен, где у меня реальный код, а где шаблонизация.
Полностью согласен, так работать с шаблоном намного удобнее. Modxsmarty пока не успел опробовать (работа срочная навалилась), но думаю скоро наверстаю. Но по опыту работы с шаблонизатором Twig (где так же есть плюшки типа вложеных циклов и логических операторов, да еще и наследование шаблонов, которые в принципе способны заменить тот же phx), могу сказать, что потом со стандартным шаблонизатором modx работаешь, так сказать с кривой улыбкой. Вроде бы все хорошо, столько всего понапихано, но скорость не та, от кучи чанков и сниппетов меню раздуто кук бурдюк. В общем было бы замечательно если бы modx из коробки поддерживал бы еще парочку шаблонизаторов на выбор)
Ага, и перетерли массив объектов $this->_relatedObjects[$alias] новым массивом массивов. Вы слышали про ссылки на объекты? Вот такой пример рассмотрим: <?php $a = $modx->getCollection('modResource', 3); $b = $modx->getCollection('modResource', 3);
$obj = $a[3]; print ($a[3] === $obj ? 1: 0); // result 1
$obj = $b[3]; print ($a[3] === $obj ? 1: 0); // result 0 Хотя это вроде одинаковые объекты с одинаковыми данными, он не равны друг другу, так как это разные инстансы (если жестко сравнивать). А вы предлагаете этот массив затирать. Конечно, может ваш метод и рабочий, может даже сбоев не будет, но он может содержать много подводных камней. Метод перебора foreach и присвоение по id дает четкое понимание что и как происходит, и не заставит программиста лезть в мануалы изучать специфики редко используемых функций.
небольшой фокус :-) <?php
print '<pre>';
$a = array(
2 => 'object'
);
$b = array( 2 => 'new object', 5 => 'object', 7 => 'object', ) + $a;
print_r($b); результат: Array ( [2] => new object [5] => object [7] => object )
Нет, так нельзя делать. Это ссумируем массивы, а нам надо заменять уже имеющиеся. Так а разве это не оно: $a = array("a" => "apple", "b" => "banana"); $b = array("a" => "pear", "b" => "strawberry", "c" => "cherry"); $c = $b + $a; var_dump($c);
// array(3) { // ["a"]=> // string(4) "pear" // ["b"]=> // string(10) "strawberry" // ["c"]=> // string(6) "cherry" // } ?
Да нет, калорий много не ушло. Просто столкнулся с новой задачей, и при реализации ее столкнулся с этой багой. $this->_relatedObjects[$alias]= $collection + $this->_relatedObjects[$alias]; Нет, так нельзя делать. Это ссумируем массивы, а нам надо заменять уже имеющиеся. Для этого правильней использовать foreach и сравнивать по id-ключу. а если не ошибаюсь, то нужен коммит, чтобы в 2.2.7 зарелизить успели Да, забыл сказать, тикет я создал: tracker.modx.com/issues/9768 С Джейсоном общался, он взял на заметку. Фикс баги не сложный, так что наверняка скоро пофиксят.
Боюсь представить — сколько нервных клеток ушло на отлов такого бага. Но по логике, правильней будет так: $this->_relatedObjects[$alias]= $collection + $this->_relatedObjects[$alias]; отсюда, хотя могу и ошибаться. а если не ошибаюсь, то нужен коммит, чтобы в 2.2.7 зарелизить успели
Если такая возможность появится штатно, будет очень здорово! Как всегда, Спасибо тебе за статью!