Jump to content
  • 0

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


DragonMX
 Share

Question

Уже несколько месяцев сопровождаю проект, написанный со 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 тогда?

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0

Когда ты работаешь над кодом один, то тебе пофиг какой инструмент выбрать для того, чтобы выполнить задачу. Но когда работает больше чем 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 кастомных функций и модификаторов, которые серьезно облегчают жизнь.

Link to comment
Share on other sites

  • 0

s0rr0w

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

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

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

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

{$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.: Не буду скрывать, что я априоре как-то отрицательно настроен против смарти, но я могу просто что-то упускать из виду. Хотелось бы разобраться.

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

  • 0

Zippovich

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

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

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

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

В папке smarty/plugins/

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

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

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

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

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

Link to comment
Share on other sites

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

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

Легко

{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}

Link to comment
Share on other sites

  • 0

s0rr0w

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

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

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

В папке smarty/plugins/

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

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

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

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

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

Edited by DragonMX
Link to comment
Share on other sites

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

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

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

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

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

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

Link to comment
Share on other sites

  • 0

s0rr0w

Легко

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

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

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

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

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

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

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

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

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

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

Link to comment
Share on other sites

  • 0

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"

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

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

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

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

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

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy