@marazmiki25 авг 2008 в 16:18

Наследование шаблонов в Smarty

4 мин

12K

PHP *

+40

Комментарии 54

@clops 25 авг 2008 в 16:25

шикарно :) ещё один повод любить смарти!

@marazmiki 25 авг 2008 в 17:19

Справедливости ради надо сказать, что подобная фишка сработает много где, даже на pure php её достаточно просто реализовать.

Но спасибо за положительный отзыв :)

@clops 25 авг 2008 в 17:25

я смарти люблю в первую очередь именно за гибкость, которая достигается плагинами… не так давно построил на них чуть ли ни целый фреймворк :)

@marazmiki 25 авг 2008 в 18:37

Делитесь идеями, они важны =)

@marazmiki 25 авг 2008 в 18:38

Делитесь идеями, многим полезно будет :)

@Urevic 26 авг 2008 в 10:32

Такими темпами функциональность smarty доведут до уровня самого php и таки напишут шаблонизатор на шаблонизаторе, написанном на языке, который сам в свою очередь изначально был шаблонизатором. Прямо дух захватывает от такой многоуровневости ;)

@faeton 28 авг 2008 в 21:33

Подробнее-подробнее!

@dasbot 25 авг 2008 в 21:09

как уже правильно заметил сам автор, это совсем не крутизна Смарти. Это идея, которую можно применить где угодно. Идея хорошая, спасибо.

@bizzona 26 авг 2008 в 07:20

Мне в смарти доставляет удовольствие его способность кешировать. Объявил какой либо шаблон, что наполняется данными, закешировал и всё база не вызывается лишний раз. Правда в одном из моих проектов таким способом бывает накешируется до 50 — 60 мегабайт (2 000 — 3 000 файлов), не знаю при поиске шаблона из такого колличества файлов — что быстрее — запрос к базе или же перебор смарти при поиске закешированного шаблона.

@marazmiki 26 авг 2008 в 08:50

Ну… тема кеширования в шаблонах — тема для отдельной статьи. И тема эта, надо сказать, противоречивая :)

@akzhan 26 авг 2008 в 11:06

хранить кэши блоков и страниц можно и не в файловой системе.

правда, обычно это делается не на уровне шаблонизатора.

например, для Drupal есть модуль cache router, который позволяет распределять кэшируемые объекты по разным хранилищам (файловая система, БД, memcached.

@crocodile2u 26 авг 2008 в 08:37

function smarty_block_block($params, $content, Smarty $smarty) — здесь имеется неточность: type-hinting нужно указывать как mySmarty $smarty — ведь в оригинальном Smarty нет методов set/getBlock.

@marazmiki 26 авг 2008 в 08:42

Не думаю, что кто-то в пределах одного проекта будет использовать и Smarty и его расширенную версию. Однако, Вы правы — это баг. Исправлю.

@krig 26 авг 2008 в 08:40

Около года назад имел дело с наследованием в смарти и решение использ-овал несколько отличное от этого.
Вечером постараюсь дома написать топик на хабр со своим вариантом.

@marazmiki 26 авг 2008 в 08:52

Будет очень интересно узнать :)

@ney 26 авг 2008 в 08:44

Не раз слышал критику Smarty, один из основных недостатков называли — отсутствие наследования шаблонов :)

Спасибо за решение.

@marazmiki 26 авг 2008 в 08:56

За решание — пожалуйста :)

А насчёт критики — занятно. Все обычно акцентируют внимание на тормознутости и «интерпретируемый язык на интерпретируемом языке», про отсутствие наследования никто не вспоминал; я, если честно, вообще не знаю на PHP шаблнизаторов с реализованным уже наследованием. Они, похоже, не существуют или не получили широкого распространения.

@dasbot 26 авг 2008 в 09:41

Ну, честно говоря, никогда не сталкивался с их жесткой необходимостью. Это интересная фишка на заметку, но зачастую она вам не пригодится. Потому она и не получила широкого распространения ;)

@marazmiki 26 авг 2008 в 10:39

Про «не пригодится» не соглашусь.

Жёсткой необходимости нет почти ни в чём. Можно ведь и не заморачиваться на ООП в целом и Смарти в частности, а просто писать код линейно и потоком, не заморачиваясь на такие мелочи, как разделение логик приложения и отображения :). Вопрос в том, насколько потом ЭТО будет легко поддерживаться.

То же самое и с шаблонами. Я уже на собственном опыте убедился, что подобный подход проще в дальнейшем расширении. Особенно актуально для создания новых шаблонов на основе уже существующих :)

@roller 9 дек 2008 в 23:50

ну в том же ZF вроде как можно из шаблона вызывать другие контроллеры (а не тот который отрабатывается сейчас). И основной контроллер совершенно не обязан о них думать. В шаблон добавляем $this->action() и понеслась

@tenshi 26 авг 2008 в 19:46

xslt. и не только на пхп…

НЛО прилетело и опубликовало эту надпись здесь

@akira 26 авг 2008 в 09:17

Хоть убейте меня, но я не понимаю чем это отличается от include?

@dasbot 26 авг 2008 в 09:39

тем, что инклуд не меняется. В случае одного блока вам понадобится два инклуда код_до и код после. В случае двух блоков, уже три итд. В случае наследования, вам всегда нужен один (если наследуемся от одного конечно).

@akira 26 авг 2008 в 09:43

был бы благодарен примером :)

@dasbot 26 авг 2008 в 09:52

он есть в посте. Там два файла parent.tpl и child.tpl в случае инклуда вам бы понадобились хидер и футер, вместо парента. Добавьте еще блок и вам понадобится хидер, футер и миддлер (гыгы).

@akira 26 авг 2008 в 09:53

Спасибо.

НЛО прилетело и опубликовало эту надпись здесь

@marazmiki 26 авг 2008 в 10:27

Если честно, не совсем понял, где в Вашем случае наследование… Расскажите поподробнее, пожалуйста.

А насчёт «ЗЫ»: что такое за*loop*ленные включения шаблонов? Если это просто инклюд шаблона внутри {loop}{/loop} или {foreach}{/foreach}, то, как мне кажется, проблем возникнуть не должно. Если ошибся — поправьте. Желательно с примерами :)

НЛО прилетело и опубликовало эту надпись здесь

@fxposter 26 авг 2008 в 09:53

if (in_array($value, $this->_blocks[$key]) === false) {
            array_push($this->_blocks[$key], $value);
        }

Вот этот момент, по-моему, лишний. Если я присвоил блоку значение, потом его переопределил, а потом хочу переопределить на предыдущее (хоть я этого, наверное, ни разу и не делал), то я хочу всё же получить последнее переопределенное значение. А так получается, что я могу написать:

parent.tpl:

Inherit it!

Just a paragraph
{block name=«foo»}It's a parent{/block}

{extends template=«parent.tpl»}
{block name=«foo»}It's a child{/block}
{/extends}

@fxposter 26 авг 2008 в 09:54

if (in_array($value, $this->_blocks[$key]) === false) { array_push($this->_blocks[$key], $value); }

Вот этот момент, по-моему, лишний. Если я присвоил блоку значение, потом его переопределил, а потом хочу переопределить на предыдущее (хоть я этого, наверное, ни разу и не делал), то я хочу всё же получить последнее переопределенное значение. А так получается, что я могу написать:

<code>{block name=«foo»}It's a parent{/block}</code>

<code>{extends template=«parent.tpl»}
{block name=«foo»}It's a child{/block}
{/extends}</code>

<code>{extends template=«parent.tpl»}
{block name=«foo»}It's a child{/block}
{/extends}</code>

@fxposter 26 авг 2008 в 09:57

Мдя… И что делать если я не дописал комментарий, он вставился непонятно с какой радости, да еще и при попытке его дописать — хабрахабр опять его вставил… :(

@marazmiki 26 авг 2008 в 10:22

Если честно, я боялся этого вопроса и вероломно о нём умолчал. С другой стороны приятно, что я заставил кого-то задуматься :)

Дело тут в том, что если эту проверку убрать, то в массив будет дампаться всё дерево наследования. И последним элементом, разумеется, будет «корень». Если непонятно, просто сделайте var_dump($template), увидите, что я имею в виду.

Я пошёл на это ограничение, исходя именно из тех соображений, что случаи, когда «внук» будет точно таким же, как его «дедушка», довольно редки и ими можно пренебречь :)

@fxposter 26 авг 2008 в 09:58

А вообще — спасибо за статью, коротко и ясно. Мне этого, честно говоря, не хватало! :)

@DeadMoroz 26 авг 2008 в 10:03

А чем хуже вынести содержимое блока, который нужно подменить во внешний файл (в несколько внешних файлов) и в зависимости от параметров эти файлы подключать? Получится композиция вместо наследования, что по сути есть более гибкое решение.

НЛО прилетело и опубликовало эту надпись здесь

@vitali 26 авг 2008 в 13:14

Я отказался от смарти когда стал использовать больше ООП.
ведь конструкция типа
{$item->getColorById(1)->getSizeById(2)->name}
не работала :-(

@marazmiki 26 авг 2008 в 13:20

Это элементарно исправляется.

@vitali 26 авг 2008 в 13:27

подскажите?
знаю только что нужно регекспы патчить, но они там такие, что чёрт ногу сломит…

@marazmiki 26 авг 2008 в 14:00

Да, нужно исправить одно регулярное выражение для разыменования объектов и методов и второе — для доступа к публичным свойствам класса. Если интересно, ближе к вечеру выложу

НЛО прилетело и опубликовало эту надпись здесь

@marazmiki 26 авг 2008 в 14:01

Хотите увидеть эту приватную версию? :))

НЛО прилетело и опубликовало эту надпись здесь

@developer 30 ноя 2008 в 09:37

решение проблеммы {$item->getColorById(1)->getSizeById(2)->name}
для смарти здесь:
habrahabr.ru/blogs/php/45651/#comment_1159897

@lexabug 3 дек 2008 в 08:53

нашел еще пару интересных особенностей этого решения.
Приведу реальный пример из своей практики.

У меня есть класс Application. Он хранит сообщения об ошибках (например неправильно заполнена форма) во внутреннем массиве $_messages. Сообщения добавляются в массив следующим методом:

    public function addMessage($text, $type = 'Error') {
        if (empty($text)) return true;
        
        if (empty($type))
        $type = 'Error';
        $this->_messages[$type][] = $text;
        return true;
    }

А извлекаются следующим методом:

    public function getMessages($type = 'Error') {
        if (empty($type)) {
            $type = 'Error';
        }
        $aMessages = isset($this->_messages[$type]) ? $this->_messages[$type] : false;
        $this->_messages[$type] = null;
        return $aMessages;

    }

А выводятся эти сообщения в шаблоне _errors.tpl, который инклудится в основном шаблоне layout.tpl, таким вот образом:

{assign var="aFailureMessages" value=$Application->getMessages('Error')}
{assign var="aSuccessfulMessages" value=$Application->getMessages('Success')}
{assign var="aInformativeMessages" value=$Application->getMessages('Informative')}

{if $aFailureMessages || $aSuccessfulMessages || $aInformativeMessages}
    <table width="100%" cellspacing="0" cellspacing="0" border="0">
        {if $aFailureMessages}
        <tr>
            <td class="error_box_red">
                {section name=failure loop=$aFailureMessages}
                    {$aFailureMessages[failure]}
                {/section}
            </td>
        </tr>
        <tr><td> </td></tr>
        {/if}

        {if $aSuccessfulMessages}
        <tr>
            <td class="error_box_green">
                {section name=success loop=$aSuccessfulMessages}
                    {$aSuccessfulMessages[success]}
                {/section}
            </td>
        </tr>
        <tr><td> </td></tr>
        {/if}

        {if $aInformativeMessages}
        <tr>
            <td class="error_box_blue">
                {section name=informative loop=$aInformativeMessages}
                    {$aInformativeMessages[informative]}
                {/section}
            </td>
        </tr>
        <tr><td> </td></tr>
        {/if}
    </table>
{/if}

Т.е. логика работы этого механизма такова, что если сообщение было выведено для просмотра значит его уже не нужно выводить.

Но каково было мое удивление, когда применяя приведенный здесь механизм наследования шаблонов, я не увидел ни единого сообщения, добавленного в Application.

В ходе отладки выяснилось, что метод getMessage вызывается по 2 раза на каждый тип сообщений, т.е. шаблон рендерится дважды!!!
Если посмотреть документацию smarty по блоковым функциям, коими являются smarty_block_extends и smarty_block_block, то они вызываются по два раза, при открытии и закрытии соответствующих тегов smarty {extends} и {block}.

В случае с smarty_block_extends дважды вызовется метод $smarty->fetch!!! вот тут собака и порылась. Таким образом, родительский шаблон рендерится дважды. Но это не оптимально — раз, и приводит к печальному результату с моими сообщениями — два.

Чтобы этого избежать, нужно рендерить родительский шаблон всего лишь один раз, когда у нас имеются данные для подстановки в теги {block}, когда был обработан шаблон-потомок, а именно во время второго вызова smarty_block_extends.

Внутри функции smarty_block_extends ставим проверку вида:

    if (!is_null($content)) {
        return $smarty->fetch($params['template'], ...);
    }
    return false;

Казалось бы, проблема решена, но! Во время переназначения содержимого блоков в таком случае данные push'атся в обратном порядке, т.е. содержимое блока из шаблона-наследника будет не на ВЕРШИНЕ стека, а на его ДНЕ. Т.е при получении содержимого блока при помощи метода getBlock, мы получим значение блока из родительского шаблона.

Решение: заменить в методе setBlock

array_push($this->_blocks[$key], $value);

на

array_unshift($this->_blocks[$key], $value);

@K1N6 10 янв 2009 в 16:22

$this->_blocks[$key][count($this->_blocks[$key])-1]
лучше заменить на
end($this->_blocks[$key])
наверное

@crYpt 29 июн 2009 в 12:54

@crYpt 29 июн 2009 в 13:05

При использовании вашего плагина для наследования шаблонов обнаружил несколько проблем:
1. базовый шаблон загружается дважды (при открывающем теге extends и при закрывающем)
2. если вставляю два наследуемых блока, а внутренний блок расширяю только для одного, то для второго будет подставлено содержимое первого вставленного блока. напрмер:

a.tpl
----
{block name=head}parent{/block}
----

b.tpl
----
{extends template="a.tpl"}
{block name="head"}child{/block}
{/extends}

{extends template="a.tpl"}{/extends}
---

при отображении b.tpl будет выведено:

child

child

Следующий код позволяет решить эту проблему:

плагины:

<?php

function smarty_block_block($params, $content, $smarty)
{
    if ( !array_key_exists('name', $params) )
    {
        $smarty->trigger_error('Block name is not set');
    }

    $name = $params['name'];

    if ( !$smarty->isBlockSet($name) && !is_null($content) )
    {
        $smarty->setBlock($name, $content);
    }

    if ( !is_null($content) )
    {
        return $smarty->getBlock($name);
    }
}

?>

<?php

function smarty_block_extends($params, $content, $smarty)
{
    if ( !array_key_exists('template', $params) )
    {
        $smarty->trigger_error('Plese set extending template name!');
    }
    
    // if open tag
    if ( is_null($content) )
    {
        $smarty->openBlocksScope();
    }
    else
    {
        $content = $smarty->fetch($params['template']);
        $smarty->closeBlocksScope();
        return $content;
    }
    return '';
}

?>

поля и методы класса SmartyX (extends Smarty)


    protected $_blocks = array(array());
    protected $_blocksScope = 0;

...

    public function openBlocksScope()
    {
        $this->_blocksScope++;
        $this->_blocks[$this->_blocksScope] = array();
    }
    
    public function closeBlocksScope()
    {
        if ( $this->_blocksScope > 0 )
        {
            $this->_blocks[$this->_blocksScope] = array();
            $this->_blocksScope--;
        }
    }
    
    public function isBlockSet($key)
    {
        return array_key_exists($key, $this->_blocks[$this->_blocksScope]) !== false;
    }

    public function setBlock($key, $value)
    {
        $this->_blocks[$this->_blocksScope][$key] = $value;
    }

    public function getBlock($key)
    {
        if (array_key_exists($key, $this->_blocks[$this->_blocksScope]))
        {
            return $this->_blocks[$this->_blocksScope][$key];
        }
        return '';
    }

@Arsenichev 14 авг 2009 в 22:56

Данный подход вызывает проблемы при использовании фильтров вывода, например сжатия страницы перед вызовом функции display:
$this->register_outputfilter( array(&$this, 'gz_compress') );

Проблема заключается в том что обвертываемый шаблон проходит дважды через фильтр вывода (первый раз при вызове функции $smarty->fetch($params['template']); а второй уже при выводе шаблона display()).

Решения проблемы пока не нашел :(

@kid 15 июн 2010 в 12:12

Вариант решения проблемы с output фильтрами:

0. Добавляете в свой унаследованный класс smarty поле is_page
public $is_page = false;

1. создаёте smarty-функцию {eop}
/**
* End Of Page
* @return
* @param object $params
* @param object $smarty
*/
function smarty_function_eop($params, &$smarty)
{
$smarty->is_page = true;
}

2. В конце главного шаблона вызываете функцию:
</body>
</html>
{eop}

3. В самом начале output фильтра проверяете, а не конец ли страницы
function smarty_outputfilter_head($tpl_output, &$smarty)
{
if (!$smarty->is_page)
return $tpl_output;
…
}

4. Правите smarty_block_extends:
function smarty_block_extends($params, $content, $smarty, $repeat)
{
/** Никому не доверяйте. Даже себе! */
if (false === array_key_exists('template', $params)) {
$smarty->trigger_error('Укажите шаблон, от которого наследуетесь!');
}

if (!$repeat)
return $smarty->fetch('pages/'.$params['template']);
}

@kid 15 июн 2010 в 12:11

Вариант решения проблемы с output фильтрами:

0. Добавляете в свой унаследованный класс smarty поле is_page
public $is_page = false;

1. создаёте smarty-функцию {eop}
/**
* End Of Page
* @return
* @param object $params
* @param object $smarty
*/
function smarty_function_eop($params, &$smarty)
{
$smarty->is_page = true;
}

2. В конце главного шаблона вызываете функцию:

{eop}

3. В самом начале output фильтра проверяете, а не конец ли страницы
function smarty_outputfilter_head($tpl_output, &$smarty)
{
if (!$smarty->is_page)
return $tpl_output;
…
}

4. Правите smarty_block_extends:
function smarty_block_extends($params, $content, $smarty, $repeat)
{
/** Никому не доверяйте. Даже себе! */
if (false === array_key_exists('template', $params)) {
$smarty->trigger_error('Укажите шаблон, от которого наследуетесь!');
}

if (!$repeat)
return $smarty->fetch('pages/'.$params['template']);
}

@col 25 июн 2010 в 14:08

Попробовал, понравилось.
Всё было хорошо пока не включил кэширование в Smarty.
Наследование тут же отвалилось, пробую понять что к чему, но изнутри Samarty знаю плохо.

Сталкивались с подобным?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий