[PHP][Smarty] Как связать переменную с шаблоном ?

Смарти уныл. Почитай про mako.

<div id="sidebar">
{if $right_menu}
<!-- right menu = {$right_menu} -->
    {include file=$right_menu}
{else}
    {include file="xfile:aviaport/right-menu/common.html"}
{/if}
</div>

...

<div class="body">
{if $this->url()|regex_match:'/(company|dealers)/'}
{include file="xfile:default/_head_company.html"}
{else}{if $this->url()|regex_match:'/technology/'}
{include file="xfile:default/_head_technology.html"}
{else}{if $this->url()|regex_match:'/retail/'}
...

Вариации разные могут быть...

>Смарти уныл. Почитай про mako.

Он есть на PHP? Или просто флудим? :)

Да, только нужно понимать, что в данном случае не совсем тру MVC. Ибо логика проникает в View. Более того - данные нужно проверять, а делать это на smarty опять не гуд.

Лучше оставить как в примерах.

> Он есть на PHP? Или просто флудим? :)

ищу :( пока ничего подобного не нашел.

>Да, только нужно понимать, что в данном случае не совсем тру MVC. Ибо логика проникает в View.

ЪMVC невозможен. Либо View проникает в Controller, либо Controller во View. В данном случае лучше второе. Ибо позволяет дизайнеру не залезать в код своими шаловливыми ручками :)

>ищу :( пока ничего подобного не нашел.

ИМХО, под PHP только три оптимальных шаблонизатора есть. Smarty, собственно PHP (у меня, да, я опять свой фреймворк рекламирую, шаблонизатор суть переменная, и сейчас, как раз, могут использоваться шаблоны на Smarty и на самом PHP) и ... блин, ну вот, забыл уже. Попадался пару раз на глаза очень вкусно описываемый шаблонизатор на Си, который в т.ч. и под PHP работал. Нагугливается CTPP, но не уверен, что его имел в виду. В общем, давно хочу пощупать, но всё руки не доходят.

> Попадался пару раз на глаза очень вкусно описываемый шаблонизатор на Си, который в т.ч. и под PHP работал

blitz

http://alexeyrybak.com/blitz/blitz_ru.html

>blitz

Нет, точно не его видел. Но посморю.

Кто-то его с CTPP сравнивал?

> blitz

блитц - уг, по функционалу до mako ему еще лет 100 ползти.

>по функционалу до mako ему еще лет 100 ползти.

А если сильно за перемещением Controller во View не гнаться, какие у mako есть сильные функциональные фишки?

Скажи, камрад, ты правда дурак или так умело притворяешься? Мы говорим о шаблонизаторах для пыха.. Блитц вообще как _экстеншен_ к _пыху_ реализован (приоритет - скорость, камрад, скорость, а не функциональность), а ты влезаешь с питоном.. Кому в данном контексте интересен твой мако?

> А если сильно за перемещением Controller во View не гнаться, какие у mako есть сильные функциональные фишки?

функционально оно может и не превосходит, а вот разделение контроллера и View хотя бы реализовано нормально. С blitz невозможно организовать разделение на controller и view

> Блитц вообще как _экстеншен_ к _пыху_ реализован (приоритет - скорость, камрад, скорость, а не функциональность)

открой для себя кэширование, да ?

> Кому в данном контексте интересен твой мако?

топик пастер не знал про мако, теперь он подумает, осознает свои ошибки и забьет на убогий пхп.

>топик пастер не знал про мако, теперь он подумает, осознает свои ошибки и забьет на убогий пхп.

Выбор языка по шаблонизатору - это очень, очень свежо и оригинально! :)

это python way :)

mako это конечно круто, но речь тут не о нем..

и все же не до конца понял как мне тут быть.. Раньше пользовался FastTemplate, там данная задача решалась легко:
$TPL->parse("CONTENT", "module1.tpl");

собсно и все, сам шаблон парсился в переменную другого шаблона.. вот, как подобное реализавать на smarty ?

Допустим я получаю имя_шаблона из БД, как теперт этот шаблон впихнуть в переменную CONTENT ?

>Допустим я получаю имя_шаблона из БД, как теперт этот шаблон впихнуть в переменную CONTENT ?

PHP:
$sub_tpl = $db->select($table, $field, $where);
$smarty->assign('sub_tpl', "{$sub_tpl}.html");

Smarty:
{capture name="foo" assign="CONTENT"}
{include file=$sub_tpl}
{/capture}

Всё, содержимое включаемого шаблона у нас в переменной Smarty $CONTENT (не уверен, но, м.б. можно опустить name="foo". По умолчанию опускать можно assign, а присвоение произойдёт Smarty-переменной $smarty.capture.foo).

как-то так:

$smarty->assign('CONTENT', $smarty->fetch('module1.tpl'));

если php5, и нужен "ленивый" рендер, возможно сработает __toString() :

class SmartyRenderMap
{
  public __construct($smarty, $tpl, array $hash) { 
    $this->smarty = /*? clone ?*/ $smarty;
    $this->tpl = $tpl;
    $this->hash = $hash;
    $this->string = null;
  }
  public __toString() {
    if (null === $this->string) {
      foreach ($this->hash as $k => $v) $this->smarty->assign($k, $v);
      $this->string = (string)$this->smarty->fetch($tpl);
      unset($this->smarty, $this->tpl, $this->hash);
    }
    return $this->string;
  }
}

$view = new SmartyRenderMap($smarty, 'module1.tpl', array('name' => 'Вася'));
...
// lazy рендер (не проверял)
$smarty->assign('CONTENT', $view);
// strict рендер (будет работать полюбому)
// $smarty->assign('CONTENT', (string)$view);
...
$smarty->display();

Супер работает !!
>не уверен, но, м.б. можно опустить name="foo"
проверил, можно опустить. И в мане написана что можно не использовать: где "foo" - значение, переданное атрибуту name. Если атрибут name не указан, то используется "default".

Теперь вот интересно чей вариант считать пионерский/*правильный*/ =)

по моему варианту все работает вот так:

PHP:
$sub_tpl = $db->select($table, $field, $where);

$smarty->assign('CONTENT', $this->adm['tpl']->fetch($sub_tpl) );

Smarty:
{$CONTENT}

Конечно в шаблоне кода меньше. Но это, думаю, не оптимально: $smarty->assign('CONTENT', $this->adm['tpl']->fetch($sub_tpl) ); ??

или как ?

>Теперь вот интересно чей вариант считать пионерский/*правильный*/ =)

От идеологии всё зависит. Если хочешь всё, касаемое шаблонов вынести
в шаблоны - то делать надо через шаблоны. Т.е. средствами Smarty.

Если хочешь немного покомпактнее и немного побыстрее - то часть
работы шаблонизатора можно и в PHP перенести.

Я выбираю обычно первый путь, он гибче. Если завтра те же подшаблоны
потребуется перенести куда-то, править придётся только шаблоны, но не
PHP-код.

Опять же, в моём фреймворке получается компактнее. Что-то типа:

class my_final_page extends base_page
{
    function local_template_data_set()
    {
        return array('sub_tpl' => $db->select(...));
    }
}

В шаблоне - останется как в моём примере выше.

Вся работа со Смарти (или другим шаблоном, если потребуется) скрыта в
недрах фреймворка, который сам организует весь вывод. В случае явного
рендеринга субшаблона через Smarty пришлось бы с ним возиться вручную.

Что не исключает такого решения в рамках объектной закрытой идеологии:

class module_module1 extends base_page
{
    function local_template_data_set()
    {
    }
}


...

class my_final_page extends base_page
{
    function local_template_data_set()
    {
        $sub_tpl = $db->select(...);
        $sub_mod = object_load('module_'.$sub_tpl);
        return array('sub_tpl' => $sub_mod->body());
    }
}

(можно, понятно, и в одну строчку:
return array('sub_tpl' => object_load('module_'.$db->select(...))->body());
но это уже не наглядно
)

И тут опять нет привязки к шалонизаторам и прямого вызова Smarty.
Скажем, один модуль может работат со Smarty, другой - с голым PHP,
третий - с CTPP.

Это уже фреймворку заботиться о привязках, не мне :)

> открой для себя кэширование, да ?

Блин, ты хоть понимаешь о чем речь идет? Точно дурак...

> Блин, ты хоть понимаешь о чем речь идет? Точно дурак...

понимаю, о убогом недоязыке.

>понимаю, о убогом недоязыке.

Зря. Ты же лучше и умнее :)

..

Языки не бывают «убогие» или «недо». Языки бывают более или менее подходящие под ту или иную задачу. И всё.

Никогда не думал что питон убогий недоязык, но тебе знать лучше

А стандартное хеадеры + футеры не подходят?

Т.е. темплейт каждого модуля выглядит как

{include file="includes/header.tpl"} 
...some module content here ...
{include file="includes/footer.tpl"} 

Да, в каждом файле придется писать этих 2 строчки.
Но если вдруг надо будет поменять для какого то модуля сделать не так как для остальных то менять это будет легко и только во view.

>Да, в каждом файле придется писать этих 2 строчки.
вот как раз лень это делать =)

пока остановился на варианте использования функци $smarty->fetch();

>Но если вдруг надо будет поменять для какого то модуля сделать не так как для остальных ....
так же все просто, если нужно показать печатную форму или еще что-то, то модуль вызывает $smarty->display('main/print.tpl') или же свой собственный(специфичный) шалон. =)