10 комментариев

avatar
Рассказываю историю:
смотрю такой в репозитории появился пакет, думаю «ух ты какая нужная вещь, нужно быстрее перевести статью» =). Потом смотрю статья на хабре про эту штуку, такой снова думаю «вот гад, успел раньше перевести, почитаю на досуге», потом смотрю такой где же ссылка на перевод… смотрю смотрю и понимаю, что argnist автор. Ну ппц =)))) ыыы. Короч выключил комп и лёг спать. Вывод: Нужно мозгам отдых иногда давать, а то они перестают работать… Вот и сказочке конец, а кто слушал, тот хоббиттец =)))
avatar
Добавить новый тег не такая уж и проблема. У меня вопрос в другом. Как MODX реагирует на этот тег? Пытается выполнить его как сниппет, и после кучи неудачных попыток вызов доходит до вашего плагина? Если так, то имя к сниппету придумано не верно. Посему, вместо [[ и ]] нужно использовать другие префиксы и постфиксы…
avatar
Нет, он парсится перед парсингом всех остальных тегов и соответственно не считается сниппетом. По моим наблюдениям получается с 1ой попытки)
avatar
Как вы это поняли?
avatar
Ну единственное несколько раз вызывается collectElementTags и несколько холостых прогонов foreach с проверкой токена по этим тегам. Но если в collectElementTags вместо префикса "[[" передавать префикс "[[#", то, например, такая конструкция [[#1.pagetitle:is=`Главная Страница`:=`[[*pagetitle]]`:else=`лалала`]] вернет неправильный тег [[#1.pagetitle:is=`Главная Страница`:=`[[*pagetitle]]
avatar
Отписал ниже про collectElementTags
avatar
Было бы прикольно добавить возможность расширять типы тегов, наряду с $, +, *, %. Думаю это не сложно сделать, немного неудобств в реализации добавят только сниппеты, не имеющие своего знака.
avatar
1) Смотрим кеш — там так и остается [[#2.pagetitle]]. Поэтому делаем вывод, что парсинг происходит постоянный. Таким образом, без кеша профита от данного плагина мало. Разве что облегчается порог вхождения в MODX… Но тут можно долго холиварить. Поэтому просто предположим, что плагин нужно дорабатывать со стороны кеша

2) Что это за пятый параметр у $modx->parser->collectElementTags? Поиск по коду
выдает core/model/modx/modparser.class.php
public function collectElementTags($origContent, array &$matches, $prefix= '[[', $suffix= ']]') {}

Но это опять не ваша вина. Накосячил тот, кто писал функцию processElementTags в core/model/modx/modparser.class.php
public function processElementTags($parentTag, & $content, $processUncacheable= false, $removeUnprocessed= false, $prefix= "[[", $suffix= "]]", $tokens= array (), $depth= 0) {
...
 if ($collected= $this->collectElementTags($content, $tags, $prefix, $suffix, $tokens)) {
...
}
...
}

Хотя может это и часть какого-то дьявольского плана.
avatar
Думаю второе это задел на будущее. Поскольку даже мне видно, что в части парсинга тегов код в MODX какой-то неООПэшный. Например, в классах тегов задается токен, но это нигде не используется, а выбор класса для обработки тега производится через switch case.

А с кешем надо думать. Дело в том, что в событие OnParseDocument не передается параметр вызван метод processElementTags c обработкой некешируемых или без них. Из-за этого могут быть проблемы, мне кажется. Сейчас в коде плагина стоит $element->setCacheable(false); В принципе можно заменить на true и тогда все будет кешироваться.
avatar
А вот еще странный код при обработке полей ресурсов:

case '*':
                    $tagName= substr($tagName, 1 + $tokenOffset);
                    $nextToken= substr($tagName, 0, 1);
                    if ($nextToken === '#') {
                        $tagName= substr($tagName, 1);
                    }

То есть обрабатывается что-то типа [[*#pagetitle]] — какой в этом смысл или это наследие старых версий? Далее нигде решетка или $nextToken не используется.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.