Объясните неповторимую выгоду Smarty и т.п.

[DragonMX]

Уже несколько месяцев сопровождаю проект, написанный со Smarty. Честное слово, до сих пор не понял его преимущества. Я добился ровно того же эффекта за вечер, сделав простой класс на php для всяких авто-include'ов с проверками, а переменные расшарил через глобальный массив. В итоге я имею те же шаблоны без использования лишего lib-нечто и его языка. Плюс к этому мои шаблоны сразу проглатываются php. В том же Smarty tpl сначала переводятся в php (вы смотрели их в кэше? банальный php!), а потом уже обрабатываются php. Зачем? Если с эквивалентным синтаксисом я могу писать это на php сразу. К тому же я не теряю возможности использования любых конструкций php в любой части кода - знаю, что должно быть четкое разделение кода и дизайна, но во время дебага всякое может пригодиться. Я, по крайней мере, не лишаю себя такой возможности.

Вот чем первый шаблон лучше второго?

{# include file='header.tpl.php' #}

Бегущая строка: {# $creeping_line #}<br>

{# foreach from=$Notes item=$Note #}
<p>{# $Note #}</p><br>
{# /foreach #}

{# include file='footer.tpl.php' #}

<?
  global $vars;
  global $App;
?>
<? $App->Include('header.tpl.php'); ?>

Бегущая строка: <?=$vars['creeping_line']?><br>

<? foreach ($vars['Notes'] as $Note) { ?>
<p><?=$Note?></p><br>
<? } ?>

<? $App->Include('footer.tpl.php') ?>

Вполне возможно, что я еще чего-то не осознал. Но пока кроме лишней либы, нового синтаксиса и запрещенного php я ничего не получил. А, и удовольствия я пока еще не получил. В чем же суть Smarty тогда?

[s0rr0w]

Когда ты работаешь над кодом один, то тебе пофиг какой инструмент выбрать для того, чтобы выполнить задачу. Но когда работает больше чем 1, то smarty - отличный способ разграничить зоны ответственности.

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

Например, есть задача показать в таблице список клиентов.

Допустим, каждый клиент описывается следующим массивом ( для упрощения записи использую JS)

{
 id: 43, 
 company_type: "ООО",
 name: "Роги и копыта",
 type: 3,
 access: 1
 }

Эти данные в чистом виде берутся из базы. Как видим, type и access - идентификаторы, а не текстовые значения.

Допустим, type=1 это демо клиенты, type=2 это коммерческие клиенты, а type=3 партнеры

access: 1 это уровень доступа к системе.

Для демо-клиентов уровень доступа всегда один - нулевой. Для коммерческих клиентов всегда 1=обычный доступ. А для партнеров 1 это обычный доступ, 2 - специальная партнерская схема.

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

Демо-доступ

Коммерческий доступ

Партнерский доступ

Расширенный партнерский доступ

Для этого мы создадим модификатор access_type, который будет модифицировать type и выводить нужную нам текстовку.

{$type|access_type:$access}

В итоге нам в любом месте, где нужно будет выводить информацию о доступе, будет достаточно применять модификатор.

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

[DragonMX]

s0rr0w

smarty - отличный способ разграничить зоны ответственности

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

Но когда работает больше чем 1

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

{$type|access_type:$access}

"Языками не владею" (с). Что для этого требуется? Описать набор (массив) соответствий access_type, где в зависимости от $type (индекс 1-й вложенности) на каждый $access (индекс 2-й вложенности) будет выдаваться некоторый результат? Типа такого?

$types = array(
  1 => array( 1 => 0)
  2 => array( 1 => 1)
  3 => array( 1 => 1, 2 => 2)
);

Если да, то где это описывается? И есть ли тогда разница с пхп?

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

Эти функции где описаны? Или, лучше будет спросить, на чем? Если можно, приведи пример какой-нибудь небольшой функции. Не могу ощутить, что смарти здесь в чем-то выше пхп. Функцию с тем же успехом может написать программист на пхп, а потом дать ее название дизайнеру, чтобы тот ее применил по месту.

P.S.: Не буду скрывать, что я априоре как-то отрицательно настроен против смарти, но я могу просто что-то упускать из виду. Хотелось бы разобраться.

[Zippovich]

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

Здесь скорее всего про разграничение верстка/логика.

Мне, как верстальщику проще править tpl-шаблоны, чем просматривать тонны ненужной мне логики. Да и смарти я могу использовать через год, два после разработки, не вдаваясь в то что там намудрил программер с шаблонизатором. Доки по смарти навиду.

[DragonMX]

Zippovich

Мне, как верстальщику проще править tpl-шаблоны, чем просматривать тонны ненужной мне логики.

Стоп-стоп-стоп. Где я сказал, что в шаблон попадает логика? Шаблон остается шаблоном, только синтаксис смарти меняется на классический пхп, а с сайта убирается ненужный компонент.

Есть ли какая-то принципиальная разница, писать {# $MyValue #} или <?=$vars['MyValue']?> ? На мой взгляд, никакой (кстати, тот же смарти прячет переменные в массив $this->_tpl_vars).

не вдаваясь в то что там намудрил программер с шаблонизатором

Да тут мудрить-то, в принципе, нечего. Все перекочевывает на обычный пхп, а там уже разработчики пхп помудрили и обкатали. Программеру остается пару полезных функций написать и наслаждаться результатом, т.е. идти писать логику.

Покажите мне такую вещь, которая удобна на смарти и не удобна на пхп.

[s0rr0w]

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

Открою вам страшную тайну, зона ответственности лежит между кодером и программером. Дизайнеры должны дизайнить, а не HTML стряпать.

Если да, то где это описывается? И есть ли тогда разница с пхп?

В коде модификатора.

Эти функции где описаны? Или, лучше будет спросить, на чем? Если можно, приведи пример какой-нибудь небольшой функции. Не могу ощутить, что смарти здесь в чем-то выше пхп. Функцию с тем же успехом может написать программист на пхп, а потом дать ее название дизайнеру, чтобы тот ее применил по месту.

В папке smarty/plugins/

P.S.: Не буду скрывать, что я априоре как-то отрицательно настроен против смарти, но я могу просто что-то упускать из виду. Хотелось бы разобраться.

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

В системах с использованием смарти код распределяется таким образом:

php : выбрать данные, передать их в шаблон

smarty : на основании данных построить нужный HTML, причем логика отображения HTML будет находиться в смарти

[s0rr0w]

Да тут мудрить-то, в принципе, нечего. Все перекочевывает на обычный пхп, а там уже разработчики пхп помудрили и обкатали. Программеру остается пару полезных функций написать и наслаждаться результатом, т.е. идти писать логику.

Покажите мне такую вещь, которая удобна на смарти и не удобна на пхп.

Легко

{capture name="ids" assign="ids"}{/capture}
{capture name="cData" assign="cData"}
 {foreach from=$data item="item"}
   <tr><th>{$data.title}</th><td>{$data.name}</td></tr>
   {capture name="ids" assign="ids"}
	{$ids}
	{$data.id},
   {/capture}
 {/foreach}
{/capture}

{if $cData|strip != ""}
<table>
 <tbody>
  {$cData}
 </tbody>
</table>
 <input type="hidden" name="ids" value="{$ids}">
{else}
 Нет данных
{/if}

[DragonMX]

s0rr0w

зона ответственности лежит между кодером и программером

Подразумевается, что один из них пишет на пхп, а другой на смарти? Если нет, то я не понял.

В коде модификатора.

В папке smarty/plugins/

Надо же! Все те же функции пхп. А смысл было городить огород, если их так же можно вызвать среди тегов? Как будто просто намерено все усложнили.

причем логика отображения HTML будет находиться в смарти

Что понимается под логикой отображения? Теги {# #} среди тегов <> </>? Разницы нет, как я уже говорил. Если имеются в виду функции и модификаторы - так сложить их в отдельную папку, все равно на том же пхп написаны.

Люди, есть ли простой пример, показывающий, что что-то минимум в два раза проще сделать на смарти, чем на пхп? Пока все сводится к разным синтаксисам и различным местам хранения кода.

P.S.: Погодите, пока писал, появился еще один пост s0rr0w. Читаю...

Edited October 16, 2009 by DragonMX

[s0rr0w]

Подразумевается, что один из них пишет на пхп, а другой на смарти? Если нет, то я не понял.

Они оба могут писать на смарти, но один заведует пхп, второй хтмл. Их зона ответственности лежит в смарти. Программеру не обязательно знать все тонкости HTML, а кодеру- досконально пхп и структуру системы.

Надо же! Все те же функции пхп. А смысл было городить огород, если их так же можно вызвать среди тегов? Как будто просто намерено все усложнили.

А смысл было придумывать языки высокого уровня, если все то же можно написать на ассемблере? Или вообще в машинных кодах? Смарти - более высокоуровневый язык. Его изучить кодеру проще, чем вникать во все тонкости пхп.

Что понимается под логикой отображения? Теги {# #} среди тегов <> </>? Разницы нет, как я уже говорил. Если имеются в виду функции и модификаторы - так сложить их в отдельную папку, все равно на том же пхп написаны.

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

[DragonMX]

s0rr0w

Легко

Вот это уже интересная задача. Основная загвоздка в функции capture - никогда раньше не приходилось так собирать данные, поэтому не знаю аналога в пхп. В любом случае, я бы это реализовал в виде $App->Capture() или $App->BeginCapture() ... $App->EndCapture(), больше пока сказать не могу. Сейчас, безусловно, готовое решение выглядит привлекательнее. Спасибо за пример.

В остальном там все аналогично синтаксису пхп.

Они оба могут писать на смарти, но один заведует пхп, второй хтмл. Их зона ответственности лежит в смарти. Программеру не обязательно знать все тонкости HTML, а кодеру- досконально пхп и структуру системы.

Ну вот как-то оно похоже на создание нескольких должностей на месте одной. Может быть, я не прав. Пусть еще мысль в голове поварится, да что-нибудь надумается.

А смысл было придумывать языки высокого уровня, если все то же можно написать на ассемблере?

Не согласен с аналогией. Мы же добавляем в смарти функции на том же пхп. Это как, если бы я для своей программы писал аддоны на ассемблере, но я-то могу их писать на том же языке.

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

Вопросы ветвления на пхп и смарти, вроде, решаются одинаково. Проблема пока только за capture. Есть еще пара таких специфичных случаев? Можно просто отправить меня к описаниям проблемных функций, маны по смарти у меня есть. Если такого добра там много, то может оно того и стоит. Хотя даже в этом случае все можно было написать в виде пхп-библиотеки и не сочинять дополнительного синтаксиса.

[s0rr0w]

Вот это уже интересная задача. Основная загвоздка в функции capture - никогда раньше не приходилось так собирать данные, поэтому не знаю аналога в пхп. В любом случае, я бы это реализовал в виде $App->Capture() или $App->BeginCapture() ... $App->EndCapture(), больше пока сказать не могу. Сейчас, безусловно, готовое решение выглядит привлекательнее. Спасибо за пример.

В остальном там все аналогично синтаксису пхп.

Аналогично но проще. Куда проще вставить две скобки и имя переменной, чем горидить обвязку пхп. Читабельность смарти-темплейтов на порядок выше.

Данный пример решается на пхп дополнительным циклом, вместо capture.

Ну вот как-то оно похоже на создание нескольких должностей на месте одной. Может быть, я не прав. Пусть еще мысль в голове поварится, да что-нибудь надумается.

Человеческие ресурсы не безграничны. Один человек не сможет никогда сделать больше, чем два, три и более.

Не согласен с аналогией. Мы же добавляем в смарти функции на том же пхп. Это как, если бы я для своей программы писал аддоны на ассемблере, но я-то могу их писать на том же языке.

Почему никто не пишет серверные веб-приложения на ассемблере?

Вопросы ветвления на пхп и смарти, вроде, решаются одинаково. Проблема пока только за capture. Есть еще пара таких специфичных случаев? Можно просто отправить меня к описаниям проблемных функций, маны по смарти у меня есть. Если такого добра там много, то может оно того и стоит. Хотя даже в этом случае все можно было написать в виде пхп-библиотеки и не сочинять дополнительного синтаксиса.

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

[DragonMX]

s0rr0w

{capture name="ids" assign="ids"}{/capture}

Аналогично но проще. Куда проще вставить две скобки и имя переменной, чем горидить обвязку пхп.

Ну я так и думал, все сводится, в основном, к 3-м функциям пхп: ob_start, ob_get_contents и ob_end_clean. В моем варианте это было бы вроде:

<? $App->BeginCapture($buffer); ?>
  ...
<? $App->EndCapture(); ?>

Но не в этом суть. Я не собираюсь принудительно конструировать велосипеды. Если бы все тоже самое было доступно в виде обычного класса, имхо, было бы больше толку. Т.е. если бы в коде выше вместо $App был $Smarty, условно говоря.

Меня в основном напрягает отдельный синтаксис.

Читабельность смарти-темплейтов на порядок выше.

Вот тут как раз есть, над чем поспорить...

{assign var="MyData" value="New value"}

<? $MyData = 'New value'; ?>

А уж это я вообще не комментирую:

$image|cat:'<td><img src="'|cat:$row.thumbnail|cat:'" /></td>'|cat:"\n"

Человеческие ресурсы не безграничны. Один человек не сможет никогда сделать больше, чем два, три и более.

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

Почему никто не пишет серверные веб-приложения на ассемблере?

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

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

Да. Возможно, именно этого мне и не хватает.