Форум PHP

Если использовать смарти синтаксис, возможно построить рекурсию на смарти?

Я в свое время от рекурсии на Смарти отказалась. Делала на php, бросала все в одну переменную, а потом пускала ее в шаблон, где добавлялся html:

<?php $list = ""; include("configs/dbopen.php"); require ("smarty/Smarty.class.php"); smarty = new Smarty; function showTree($parent_id,$level) {   global $link, $list;   $sql = "SELECT * FROM `menu` WHERE `pid` = ". $parent_id ." ORDER BY `id_menu`";   //echo $sql."<br>";   $result = mysql_query($sql) or die (mysql_error());      if ($level > 0 && mysql_num_rows($result) > 0) {      $ulopn = "<ul>";      $ulcls = "</ul>"; } else $ulopn = $ulcls = "";   $list .= $ulopn;   while ($row = mysql_fetch_row($result)) {     $list.= "<li><A HREF=\"?id_menu=$row[0]\">".htmlspecialchars($row[2])."</A>";     showTree($row[0],$level+1);     $list.="</li>";   }   $list .= $ulcls; } showTree(0,0); $smarty->assign('menu', $list); $smarty->display("menu.tpl"); ?>

да так не хочется, я давно отказался от мешанины html и php, для этой задачи на мой взгляд лучше написать плагин для смарти...

в том то и дело, что хотелось бы на смарти сделать рекурсию, чтобы не было смешение языков...

Легко

tree.tpl

{if $tree} <ul class='tree'> {foreach from=$tree item="item"}     <li>{$item.name}         {if $item.subtree}             {include file="tree.tpl" tree=$item.subtree}         {/if}     </li> {/foreach} </ul> {/if}

{if $tree}  <ul class='tree'>  {foreach from=$tree item="item"}      <li>{$item.name}          {if $item.subtree}              {include file="tree.tpl" tree=$item.subtree}          {/if}      </li>  {/foreach}  </ul>  {/if}

Так это уже и есть смешение верстки и кода. Тогда зачем вам smarty?

какого кода? это чисто макет. код держите в приложении - тут он не нужен

Код

{if $tree}

Верстка

<ul class='tree'>

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

Так к каждой произвольной рекурсии придется на лету делать шаблоны.)

css вам в зубы:)
Этот шаблон покрывает процентов 90 случаев... а может даже 91;)

Я не об оформлении, а об элементах. Если надо чуть изменить, значит нужен новый пассивный шаблон. Не проще ли отдать массив (как результат рекурсии) в шаблон, а к нему прикручивать элементы?

Вот именно

>Если надо чуть изменит
что чуть изменить?

>значит нужен новый пассивный шаблон
кому нужен?

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

Вообще давайте не на пальцах: я код привел. Он рабочий читаемый и компактный. Если вы можете показать код отвечающий тем же условиям - буду признателен.

Рекурсивным запросом я получаю дерево - во всю глубину и ширину. Этот массив я отдаю в шаблон, и в этом единственном шаблоне я могу разложить его как по вертикали, так и по горизонтали, изменять элменты этого дерева, стили... То есть, все это можно делать одним шаблоном, только лишь указывая условие - "как". В вашем же случае, потребуется несколько шаблонов, которые нужно будет готовить отдельно - в чем выгода от этого?

код можно?

Какой код, стандартно раскладваем массив средствами Смарти. Или вы хотите сказать, что их не хватает?

>средствами Смарти
А я какими средствами его разложил?

Собственно, я хочу увидеть как можно разложить "средствами Смарти" дерево с неограниченной вложенностью, с созданием корректной объектной модели не прибегая к рекурсии. Желательно чтобы дизайнер при виде макета не покончил с собой. Покажете, наконец?

Хорошо, но позже, мне ноут принесли, нужно сделать. Но что-то вы не туда. Я получаю дерево, а это значит знаю уровни вложения, характеристики уровней, и проверяя эти значения построить нужное, труда не составит. Это то же, что и вы делаете, только я в одном шаблоне, а вы несколькими ;-)

Зря взялся за этот ноут, только время потерял.) Что касается вывода. Значит так. Я получаю рекурсивным вызовом дерево каталогов, соответственно сортированное, с вложением по родителю. Так я раскладывал массив для древовидного меню. Шаблон формировался под меню товаров (потому по памяти пишу о них:)). Наличие ссылки в меню определялось наличием товаров в категории, этим же условием определялся и класс элемента меню. Условием вложения элементов (их закрытие) служило id родителя категории. Например, массив товаров будет такой:

<? $tree = array( array('name'=>'Украшения','id'=>1,'par'=>0,'prod'=>10), array('name'=>'Косметика','id'=>2,'par'=>0,'prod'=>0), array('name'=>'Люкс','id'=>3,'par'=>2,'prod'=>10), array('name'=>'Крема','id'=>4,'par'=>2,'prod'=>0), array('name'=>'Такие','id'=>5,'par'=>4,'prod'=>10), array('name'=>'И вот такие','id'=>6,'par'=>4,'prod'=>10), array('name'=>'Чего-то','id'=>7,'par'=>2,'prod'=>10) );

А так в шаблоне:

{section name=i loop=$tree}   {if !$tree[i].prod}     <div class="folder">{$tree[i].name}   {else}     <div class="doc"><a href="?cat={$tree[i].id}">{$tree[i].name}</a>   {/if}   {if $tree[i.index_next].par ne $tree[i].par and $tree[i].prod}     </div></div>   {else}     {if $tree[i].prod}</div>{/if}   {/if}   {/section}

На мой взгляд, этот вариант принципиально не отличается от варианта предложенного Леной в начале треда: тоже перекладывание проблем представления на логику приложения. То есть в конечном итоге в шаблон передается не структура дерева, а некая разжёванная кашица с костылями для отрисовки.
Но вариант рабочий. Спасибо! Буду иметь его ввиду;)

Loki, ну на вас не угодишь :) Я просто получаю массив дерева (чистая РНР часть) и отдаю шаблонизатору, че ему тут разжевывать? :) Что значит кашица? Ну а как я должен в рекусивном запросе получать дерево - "каком к верху"? :)

Как-то это ... хм... странно слышать.
Я может чего и не понимаю в шаблонизаторах, но
Вариант в начале треда передавал шаблонизатору готовые теги.
Которые применялись не для построения представления, а для голой выдачи наружу.
Здесь же передается именно что структура дерева.

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

Значит я враг самому себе, и делая запрос на выборку из базы дерева, разбросаю записи как попадя?:) Нафига она нужна такая выборка? Я так выбираю с учетом того, что мне возможно потребуется вывести на страницу уже раскытое дерево. Если и в этом случае делать рекурсию в Смарти, то это вообще было бы из рук вон. Я бы поступил проще - также сортированное дерево с иерархией вложения, плюс добавление к записям уровня вложения. Останется просто при разложении массива в шаблоне, например, добавлять к имени класса элемента уровень вложения, а в соответствующем классе указать padding-left, или просто банально добавить соответствующее число   слева.
Есть оправданные условия когда можно и в Смарти вызвать рекурсию, но вот для меню, которые и нужно сортировать, и которые имеют максимум 3-4 уровней в ширину, я бы не стал такого делать.

С такой точки зрения советую вам использовать smarty

Loki предложил реально рабочий, простой и структурно понятный вариант реализации обработки дерева на смарти, чем он вам всем не нравится??
А самое главное что его вариант использует смарти действительно как "шаблонизатор".

Интересует только одно, насколько быстро это будет работать?