Народ, сегодня я хочу к вам обратиться с призывом!
В последнее время я все чаще и чаще слышу от MODX-разработчиков о том, что MODX очень сильно теряет в популярности именно из-за того, что некоторые популярные пакеты создают кошмарное представление о самом MODX-е. Простой пример: некто ставит MODX Revolution (все мы знаем, что это отличная платформа, и здесь вообще вопросов никаких нет). Но ведь самой голой системы не достаточно. Надо же поставить необходимые модули, чтобы выводить новости, развернуть магазин и т.п. И вот как по вашему должен реагировать разработчик, когда он ставит пару пакетов, в которых десятки тысяч строк кода, в которых черт ногу сломит, а еще и все ужасно тормозит?! Реакция очевидная. И в результате мы имеем уже очень низкий рейтинг самого MODX-а. Сам лично уже не раз наблюдал фразы типа «ставим минус просто за то, что это MODX».
Пришло время кардинально это дело поменять. И мы можем это сделать.
Корень зла и всех бед — это повсеместное использование чанков и сниппетов (в общем все то, о чем я говорил много раз уже). Разработанные и используемые мной в каждом новом проекте пакеты типа phpTemplates — это решения, позволяющие значительно увеличить производительность, а так же облегчить сопровождение MODX-проекта.
Приведу список с краткими описаниями этих пакетов:
1) phpTemplates — позволяет использовать статические MODX-шаблоны как обычные php-файлы. То есть с использованием phpTemplates мы не просто храним некий статический код в шаблоне, а получаем нужную нам php-логику еще на уровне шаблона. А здесь мы можем уже и сторонний шаблонизатор использовать, и просто php-код выполнить, и отдать на вывод конечный результат, который будет закеширован MODX-ом, и в дальнейшем будет отдаваться как простой HTML-код, без лишнего парсинга. Таким образом наши шаблоны превращаются в контроллеры, а шаблонизация уже уходит на уровень специализированной системы шаблонов.
2) modxSmarty — специально адаптированный для MODX шаблонизатор Smarty. В Smarty-шаблонах вы можете использовать как нативные MODX-теги, типа [[Wayfinder]], так и специально написанные для Smarty теги типа {snippet name=Wayfinder}. В чем разница и какой смысл от этого?
1. Производительность. Когда вы используете классический [[Wayfinder]], то этот тег сначала должен быть найден MODX-парсером (строковые операции), затем парсер его разбирает на предмет параметров и т.п., затем находит и инициализирует объект (modSnippet), получает результат выполнения этого сниппета, затем делает реплейс MODX-тега в общем коде вывода этим результатом, а в итоге еще и записывает это все по отдельности в кеш документа (то есть не сразу конечный код, а тег отдельно, результат его отдельно).
К примеру, вот кусочек кеша документа:
'_content' => '<!DOCTYPE html> <html lang="ru-RU"> <head> <title>[[*pagetitle]]</title> <!-- base xhtml4 --> <base href="http://btj.fi1osof.modxcloud.com/" /> <meta name="robots" content="noindex, nofollow" /> <link rel="canonical" href="http://btj.fi1osof.modxcloud.com/common/404.html" /> <meta http-equiv="content-language" content="ru" /> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <meta http-equiv="pragma" content="cache" /> <meta http-equiv="cache-control" content="cache" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <meta http-equiv="Content-Script-Type" content="text/javascript" /> <!-- meta --> <meta name="keywords" content="[[$AllKeywords:notempty=`[[$AllKeywords:strip]], `]]" />
Это кеш документа, в шаблоне которого используются кешируемые MODX-теги. При этом, как видите, эти кешируемые теги на месте. То есть не конечный код на их месте, а именно сами теги. А значения этих тегов отдельно. Вот кусочек:
'elementCache' => array ( '[[*contentType:lcase]]' => 'text/html', '[[*keywords:strip]]' => '', '[[*description:strip]]' => '', '[[*description:notempty=`<meta name="description" content="" />`]]' => '', '[[%page_not_found]]' => 'Страница не найдена', '[[*longtitle:replace=`<br />== `:replace=` == `:striptags]]' => 'Страница не найдена',
То есть, даже если документ полностью закеширован, все равно при каждом заходе на страницу, MODX будет делать разбор кеша с целью поиска тегов и замещения их результатами (опять-таки куча строковых операций, инициализаций объектов и т.п.).
Все еще удивляетесь почему ваш MODX-сайт тормозит?
А что делает modxSmarty? Когда тег обрабатывается на уровне Smarty, типа {snippet name=Wayfinder}, тогда результат выполнения сразу же попадает в вывод уже в виде конечного HTML-кода. То есть в кеш документа в _content уже будет записан HTML-код без MODX-тегов. А значит MODX-парсер будет значительно разгружен, ему не придется обрабатывать кучу тегов, реплейсить их результатами и т.п. Поверьте, что нагрузка снижается в разы сразу.
2. Более гибкая шаблонизация. Здесь бы сразу отметил две очень важные фишки: расширение шаблонов (чего нет в MODX-е в принципе) и практически полная поддержка php-функций (то есть так необходимые циклы, условия, форматирование и т.п.).
Плюс ко всему еще и полная поддержка объекта $modx. К примеру, в шаблоне вы легко можете выполнить вот так:
{foreach $modx->resource->getMany('Children') as $child} <br />Название дочернего документа: {$child->pagetitle} {/foreach}
Такую простую операцию вы в MODX-е без использования дополнительного сниппета в чанке не сделаете. А это дополнительные объекты, память, время.
3) shopModx. Не смотря на то, что это модуль для создания интернет-магазинов на MODX Revolution, я использую его во всех своих текущих проектах. Точнее не сам модуль, а входящие в него list-процессоры (я так называю процессоры, предназначенные для выборки данных объектов). Так вот, в состав shopModx-а входит getdata-процессор, который делает выборку не только документов, но и всех их TV-параметров, и возвращает результат в виде очень удобного массива (все TV-параметры идут в ключе tvs). И вот эти процессоры очень удобно выполнять в Smarty-шаблонах и выводить результат (хотя можно конечно и с ниппетах и в плагинах вызывать эти процессоры через $modx->runProcessor(), но все-таки львиная доля вызовов приходится на Smarty-шаблоны). Вот пример:
{processor action="web/getdata" ns="mynamespace" params="param1=`data`¶m2=`data`" assign=result} {* Проверим права на просмотр отладочной информации *} {if $modx->hasPermission('debug')} {* Посмотрим на все данные ответа *} <pre>{print_r($result)}</pre> {/if} {if $result.success} {* Выведем результат *} {foreach $result.object as $object} <div> ID документа: {$object.object_id}<br /> Заголовок документа: {$object.pagetitle}<br /> Опубликован: {date('Y-m-d', $object.publishedon)} <h2>TV-параметры:</h2> {foreach $object.tvs as $tv_name => $tv} Название TV-поля: {$tv_name}<br /> ID: {$tv.tv_id}<br /> Значение: {$tv.value} {/foreach} <div> {/foreach} {else} Error: $result.message {if}
И здесь можно с этим делать все, что угодно.
Но дело не только в удобстве (включая расширение процессоров и т.п.). Дело еще и в производительности. Выборку 500 документов за раз делает менее чем за 0,01 сек.
4) Console. Это один из самых простых моих пакетов, и при этом один из самых полезных :-) Он позволяет в админке выполнять произвольный php-код с полной поддержкой MODX-окружения. То есть можно сделать выборку документов, модифицировать их, сохранить и т.п. Так же можно выполнить сниппеты, процессоры и т.д. и т.п. В общем все, что угодно.
Но еще я его вот как использую: я часто на сайте пишу собственные формы на Smarty+процессоры, а не использую eForm или типа того. При этом в вызов процессора в качестве параметров передается $smarty.post или $smarty.get (в зависимости от задачи). То есть на уровне процессора эти параметры доступны через $this->getProperies() и $this->getProperty($property). А это значит, что процессор себя будет вести точно так же, если я его буду вызывать в консоли с передачей в него произвольного массива параметров, типа $modx->runProcessor($action, $properties);
В общем, отладкой форм я занимаюсь прям в консоли, получая все ошибки и т.п., не тратя время на перезагрузку страницы, повторное заполнение формы и т.п.
Плюс такого подхода еще заключается и в том, что обработчик формы становится полностью универсальным, и его можно хоть со страницы вызывать, хоть через коннектор, хоть через плагин и т.п. Везде логика будет одна и та же, только вывод меняй при необходимости.
Резюме
В общем, я твердо убежден, что эти технологии позволят использовать MODX Revolution более качественно и выгодно. И сейчас надо просто сделать так, чтобы об этих технологиях узнало побольше MODX-еров и начали брать их на вооружение. И вы можете этому помочь: ставьте «лайки» этим пакетам на modx.com (им не много надо для выхода в ТОП), да и сами берите на вооружение.
Любые вопросы по ним можете задавать здесь.
Лайкнул каждый пакет. Давайте поддержим Николая, ведь реально хорошие вещи делает.
Спасибо! :-)