Сегодня оптимизировал работу одного сайта и хочу дать пару советов, которые могут пригодиться многим начинающим программистам, особенно тем, кто по большей степени ведет разработку на уровне тегов MODX.
Кстати, сразу отмечу, что это сайт-визитка, и все страницы кешируемые за исключением отдельных блоков.
Итак, самый главный минус, с которым я столкнулся. В большинстве шаблонов контент страницы выводился через пользовательский чанк, в котором уже был прописан тег [[*content]].
Вот полный листинг этого чанка:
Здесь предлагаю обратить внимание именно на конструкции типа [[*parent:is=`240`:then=`…
В чем же здесь проблема? Проблема в том, что MODX-парсер работает не так, как, к примеру, php-интерпретатор. По логике вещей здесь должно быть следующее: если ID родителя текущего документа равен 240, то выполняется блок Then.
По логике Да, а на практике Нет. Покажу простой пример как обрабатываются условия на php, чтобы показать, чего не происходит. Вот простой код:
Так вот, в данном примере, если parent не будет равен 240, то функция time() не будет выполнена в принципе. При парсинге MODX же содержимое блока выполнится в любом случае, просто будет результат выведен на странице или нет, определит истинность условия.
В данном случае независимо от условия MODX-парсер выполнил полностью блок Then, а только потом на основе условия решит выводить результат этого блока или нет. То есть не зависимо от того, какой родитель у документа, все блоки в этом чанке будут выполнены. А меж тем этих блоков здесь четыре, при этом два из них — НЕкешируемый сниппет getPage. То есть даже если страница уже закеширована, каждый раз при обращении к ней MODX будет обрабатывать эти сниппеты, потому что они некешируемые.
Как результат: 5-10 секунд на генерацию кода закешированной страницы против одной секунды с исправленной логикой.
Здесь мы подобрались к тому, как же правильней прописывать подобные вещи. Мой совет: меньше используйте чанки, больше сниппеты. Не смотря на то, что чанки психологически воспринимаются более простыми элементами (так как в них вроде как HTML, а не исполняемый php), тем не менее их использование накладывает дополнительные расходы, так как дополнительно нагружают парсер.
Плюс, как я писал здесь, в чанках вы управляете кешем элементов только на уровне текущего документа, а не на уровне всего сайта. Потому старайтесь придерживаться правила: всякая логика в сниппетах, оформление в чанках.
Как же было бы правильней реализовать логику?
1. Создаем чанк, который будет у нас шаблоном для вывода результата работы сниппета.
На заметку: здесь есть два плейсхолдера: pre_content и post_content. При создании чанков, если не уверены в том, что для всех плейсхолдеров будут переданы переменные, на всякий случай создайте пустые Параметры для этого чанка. В нашем случае это Параметры pre_content и post_content. Не знаю насколько сейчас пофиксили, но раньше парсер до 10-ти раз пытался «найти» переменную, пережевывая чанк.
2. Создаем сниппет.
В этом сниппете мы не прописали дополнительное кеширование, но для нас сейчас главное то, что блоки внутри условий будут выполнены только тогда, когда условие будет выполнено. За счет этого мы на практике очень сильно сократили время на генерацию страницы.
В итоге код не стал запутанней, но производительность выросла сильно.
И напоследок совет: не храните много кода в шаблонах. На многих сайтах страницы имеют одинаковые шапку и подвал на всем сайте (как правило только главная может существенно отличаться). Так вот создайте общие чанк header и footer, и подгружайте их в каждом шаблоне, чтобы не пришлось потом везде менять, если какой-то блок надо изменить. А то представьте сколько движений надо сделать, чтобы поменять дизайн и логику на сайте, на котором штук 15 вот таких шаблонов:
Т.е. при работе с условиями при вызове "снипета с различными параметрами" либо "различными сниппетами" всю логику лучше реализовать в отдельном сниппете?
По хорошему да. Но это не всегда бывает удобно просто из-за того, что сниппеты не умеют возвращать массивы или объекты, а только строку, а на каждый чих чанк создавать - тоже не комильфо. Поэтому мы давно уже ушли от сниппетов в сторону процессоров + Smarty.
ну кстати пздтц какой то))))
Делаю например вызов снипета:
[[!testSnippet?
&browser = `[[!+modxSiteTemplate]]`
&tpl = `0`
]]
Сам снипет (testSnippet):
<?php
$browser = $modx->getOption('browser', $scriptProperties, '');
$tpl = $modx->getOption('tpl', $scriptProperties, '');
if($tpl == 0) {
echo «я для tpl = 0»;
// Быстро обработался
}else{
echo «я для tpl != 0»;
// Тут какой нить код запроса или еще что нить что обрабатывается долго или просто же die(); Например -:)
die();
}
Какого хера обработается die(); и при вызове testSnippet с параметром &tpl = `0`?
1. Первое предупреждение за нехорошие слова.
2. Попробуйте все-таки посмотреть что у вас за $tpl. Сделайте так:
<?php $browser = $modx->getOption('browser', $scriptProperties, ''); $tpl = $modx->getOption('tpl', $scriptProperties, ''); // Смотрим содержимое и тип переменной var_dump($tpl); exit; if($tpl == 0) { echo «я для tpl = 0»; // Быстро обработался }else{ echo «я для tpl != 0»; // Тут какой нить код запроса или еще что нить что обрабатывается долго или просто же die(); Например -:) die(); }
Что выведет? Какая переменная?
ну или &tpl = `true` а в снипете if($tpl) все равно… как не крути обрабатываются все условия if
да, там строка, string, согласен.
Не пустая строка? То есть длина более нуля?
Вообщем я делаю так:
Шаблон:
[[!If?
&subject=`[[!+modxSiteTemplate]]`
&operand=`full`
&then=`
full
[[$fullTemplate]]`
&else=`
mobile
[[$mobileTemplate]]`
]]
Чанк fullTemplate:
fullTemplate
[[!testSnippet?
&browser = `[[!+modxSiteTemplate]]`
&tpl = `true`
]]
Чанк mobileTemplate:
mobileTemplate
[[!testSnippet?
&browser = `[[!+modxSiteTemplate]]`
]]
Если в снипете (testSnippet) делать так:
<?php
$browser = $modx->getOption('browser', $scriptProperties, '');
$tpl = $modx->getOption('tpl', $scriptProperties, '');
if($tpl) {
echo «я для fullTemplate»;
}else{
echo «я для mobileTemplate»;
}
То выводится все правильно. для мобилы снипет отдает echo «я для mobileTemplate»; для пр. echo «я для fullTemplate»;
НО если поставить в первое или последнее условие if например die();
или просто бесконечный цикл какой — нить… то обработает этот die() и для mobileTemplate и для fullTemplate.
То есть вы понимаете о чем я?
То есть вы понимаете о чем я?
Думаю да, понимаю. 99% расклад такой: не зависимо от того, какое у вас условие на уровне шаблона (я про [[!If?), чанки [[$fullTemplate]] и [[$mobileTemplate]] будут отработаны в любом случае. Это особенности MODX-парсера. Это вам не чистый php, где если условие if() не выполнилось, то и внутри него ничто не выполнится. А здесь If — это даже не функция, а просто тег (если говорить про шаблонизацию). В результате он или выведет, или не выведет результат. Но результат внутри в любом случае будет, то есть внутренние теги отработаются.
Это одна из серьезных таких причин, по которой мы используем modxSmarty, а не нативную шаблонизацию MODX-а. На уровне Smarty это было бы так:
{$modxSiteTemplate = $modx->getPlaceholder('modxSiteTemplate')} {if $modxSiteTemplate == 'full'} full {chunk name=fullTemplate} {else if $modxSiteTemplate == 'mobile'} mobile {chunk name=mobileTemplate} {/if}
Вот тут четко будет или одно выполнено, или другое.
Если хотите делать на чистом MODX-е, тогда не сниппет If вызывать надо, а свой сниппет напишите, который четко по условию будет вызывать тот или иной чанк.
return $modx->getChunk($chunkName);
P.S. Код надо оборачивать в теги <code>
?
Да, спасибо. -:)
Большое спасибо за статью!
Как раз хотел сократить кол-во шаблонов с помощью фильтров вывода, статья отговорила))
Только не нашел вызова снипета, или его вызывать не обязательно?
Заранее спасибо!
Вы сниппет этот и вызываете там, где должен выводиться контент.
Но вообще у меня там была формулировка «Как правильней». Это в данном случае, учитывая убогость изначальной основы заложенной предыдущими программистами. А вообще, так как я написал, мы и сами уже не делали бы, это я все давно писал. Сейчас у нас Smarty и расширяемые шаблоны с блоками.
Точно, извиняюсь — нашел
<div class="my_box"> [[Template.Content_simple]] </div>
Спасибо.
Ну до Smarty мне пока рано )
Не за что.