Да в новой версии вопросы были только в интерфейсах в адмике (типа компонента modxSDK). А так в целом там все тоже самое, так что ничего там особого не поменялось (во всяком случае чего-то такого, что свело бы на нет ту инструкцию).
Если в двух словах (на большее тож не обижусь :) ), насколько актуальна эта инструкция для новой версии сборки и что там нужно изменить, чтобы и на новой канало? Просто неясность в этом вопросе единственное, что меня останавливает от перехода на новую версию. А по-скольку я немного отошел от инструкции, разбираться мне сейчас особенно неудобно.
Лезть в modxsmarty.class.php — это перебор. Короче if/else в главном лейауте остается пока самым простым и железобетонным способом.
Да, указать переменную шаблона действительно можно, просто из прошлого коммента подумалось типа {if}{extends ...}{else}..{/if}. Такое там не канает. А с переменной получается следующее:
1. В __construct лезть не оязательно, у нас же за все отвечает единый контроллер base.php
Прописываем в нем условие:
<?php // .................................. if($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'){ $modx->setOption('layout', 'ajax-layout.tpl'); $compile_id = 'ajax'; } else{ $modx->setOption('layout', 'layout.tpl'); $compile_id = 'layout'; } return $modx->smarty->fetch("tpl/{$tpl}", '', $compile_id);
Обязательно задаем разные $compile_id, иначе не будет перекомпиливаться уже отработанный шаблон.
2. Создаем ajax-layout.tpl В нем пишем:
{block name=content} {$modx->resource->content} {/block}
3. Создаем промежуточный switch-layout.tpl, с содержимым:
{extends $modx->getOption('layout', null, 'layout.tpl')}
Здесь один минус есть: в рабочем режиме у шаблонов переменная phptemplates.non-cached == false, и Smarty-шаблоны при повторном заходе не отрабатываются. Так что придется некеширование выставлять в true, что конечно же скажется на производительности. Можно конечно в настройках modxSmarty включить кеширование самих смарти-шаблонов, но это усложняет разработку, ибо надо будет более четко продумывать где что кешировань/не кешировать, и прописывать где надо nocache. Но если это правильно использовать, то нагрузка не должна увеличиться так, чтобы заметно было.
P.S. За полезный коммент поднимаю права до члена Клуба :)
Надо просто учитывать, что в отличие от return где-нибудь в блоке присвоения значений в php-коде, в смарти это буквально в блоке вывода echo/print, из-за чего мы обламываем таким образом процесс вывода, а не процесс присвоения.
да, правда только в верхнем layout. поставил перед футером — отсекает. правда, тоже нет — сейчас посмотрел :(
В Smarty в {extends ....} можно использовать переменную, примерно так: {extends $modx->layout}
а $modx->layout можно где-нибудь определить
скажем в modxsmarty.class.php в конструкторе:
... ... function __construct(modX &$modx, $params= array ()) { parent :: __construct(); $this->modx= & $modx; $this->modx->layout= $_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest' ? "layout.tpl" : "<strong>empty_layout.tpl</strong>"; ... ...
В общем, я пробовал по всякому. Ничего нормального тут не получается. Но поделюсь одним нестабильным элементом:
Весь главный шаблон оборачиваем в блок, к примеру resource.
Далее создаем новый промежуточный layout-wraper.tpl с таким содержимым
{extends "layout.tpl"} {block name="resource"} {if $is_ajax} {block name=content} {$smarty.block.parent} {/block} {else} {$smarty.block.parent} {/if} {/block}
Здесь важно, чтобы блока content не было в главном layout-шаблоне. Вот тогда при вызове какого-либо более глубокого расширяемого шаблона по условию выводился только блок content. Но у меня это было очень не стабильно. Это скорее бага, чем фича. Если захочешь с этим поэкспериментировать, то до конечного шаблона создай еще один расширяющий шаблон, в котором будет только расширение прописано {extends ...} и все. Мне сейчас совсем некогда ковырять глубоко Смарти, чтобы объяснить такое странное его поведение. Коммент оставляю, чтобы возможно на досуге вернуться к изучению этого интересного явления.