Почему я отказался от использования Smarty

Краткиий экскурс в историю

Когда я пришел на работу в одну американскую контору (удаленно конечно. и было это году так в 2000), то вынужден был использовать стандарты, принятые в этой организации. И одним из них было использование своего шаблонизатора, который выглядел как простой html файл, в котором могут присутствовать специальные последовательности символов (обычно начинающиеся и заканчивающиеся на "##"), которые перед выдачей в броузер будут заменены на тексты или результаты работы других шаблонов. Также там был свое API для работы с такими шаблонами. Очень простое API. А так как я был в то время очень молод, то я принял на вооружение эти стандарты и стал использовать их в своей работе.

Вот пример работы с таким шаблоном:
    $template = new Template();
    $template->Load('NameTemplate.html');
    $template->Replace('##TITLE##', 'Hello world!');
    $template->Out();


Знакомство

Шли годы. И при реализации очередного проекта возникло требование: «В качестве шаблонизатора обязательно использование Smarty». Партия сказала: «Надо». Комсомол ответил: «Есть!». Так я и познакомился со Smarty. Он мне очень понравился. Я просто был вне себя от восторга. Любая задача которую мне надо было реализовать, могла быть реализована с его помощью. Иногда просто, иногда очень сложно, но можно. В общем, я стал использовать Smarty.

Прозрение

Прошло еще несколько лет. Не помню почему, но возникла задача найти простой для работы фреймворк на php. Я нашел их список и стал их тестировать для наших целей. Естественно одним из требований было: поддержка Smarty (и это было уже мое требование). При чтении документации одного из фреймворков (то ли Kohana, то ли CodeIgniter) я встретил фразу примерно такую: «Вы можете использовать Smarty, вот тут инструкция как его подключить и как с ним работать в нашем фреймворке, но мы считаем что нативный php проще, понятнее и быстрее ...». И я задумался. Стал сравнивать реализации на нативном php и Smarty.

Проще? Конечно, ведь php мы уже знаем.
Понятнее? Конечно, ведь php мы уже понимаем.
Быстрее? Конечно, ведь код на Smarty будет транслироваться в код на php (и как минимум быстрее он быть не может, а медленне запросто).
Безопаснее? Я думаю да. Хотя тут можно поспорить. Дырок можно наделать где угодно.

Cмотрите сами:
{$foo} против <?=$foo?>


{assign var=foo value='baa'} против <?php $foo = 'baa'; ?>


{include file='header.tpl'} - реализация этого на php зависит от разных факторов от <?php include 'header.php'; ?> до более сложных вариантов (все зависит от фреймворка)


{assign var="foo" value="`$foo+$bar`"} // помню, всегда искал это в документации.

<?php 
	$foo += $bar; 
?>


Примеры условий и циклов приводить не буду — занимают много места и выглядят примерно одинаково.

Еще помню как на Smarty делал реализацию рекурсивного обхода дерева, один из вариантов это создание шаблона и вызов этого шаблона внутри себя. На php это выглядит так:
<?php
	function draw_tree($tree){
		foreach ($tree as $node)
		{
			echo '<option ...>'.$node['name'].'</option>';
			draw_tree($node['childs']);
		}
	}
?>


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

PS. Smarty не использую уже года 2-3, и потому текущее состояние дел мне оценить сложно, но думаю дела обстоят не лучше и не хуже чем было раньше.
Метки:
Поделиться публикацией
Похожие публикации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 71
  • –7
    Я со Smarty почти не работал, но одно могу сказать точно: в Smarty логика и представление слишком связаны, что очень сильно мешает. Хорошо, если вы сами занимались разработкой проекта, но стороннему разработчику довольно сложно в эту мешанину вникнуть сходу.
    • 0
      Каким образом связана логика с представлением в смарти? Если Вы реализовываете логику на смарти это не значит, что смарти плох.
      А по поводу безопасности так если вы используете native php — какая безопасность если можно вызвать всё? в смарти есть только определенный набор разрешенных функций которые можно вызывать. т.е. по сути можно сделать что бы клиенты вашего сервиса правили свои шаблоны и это будет безопасно в отличии от native php.
      ЗЫ. для рекурсий есть {function}
      • 0
        Если Вы реализовываете логику на смарти это не значит, что смарти плох.
        Так я же написал
        но стороннему разработчику довольно сложно в эту мешанину вникнуть сходу.

        Приходилось дорабатывать проект с такой кашей. Хотя, это скорее проблема того разработчика, а не Smarty.
        • 0
          Сложный шаблон на чистом PHP производит намного более удручающее впечатление…
          Запись без шаблона — <? if (isset($item['key']):?> <?= $item['key'] ?> <? else: ?> default <?endif ?>
          тоже самое в смарти — {$item.key | default:'default'}
          • –2
            Я на чистом php стараюсь не писать, как правило использую фреймворки вроде Zend, где всё довольно красиво.
            • +1
              в Zend-е другие if-ы? :)
              • –1
                Там подобное в помощниках вида или в контроллере, а не всё в куче.
                • +2
                  То есть, что бы написать один if нужно вызвать четыре класса и сделать пару записей в сингелтон?
                  • –2
                    Вы специально всё утрируете?

                    Если у вас всего один if и выводится одна переменная, то вам шаблонизаторы вообще не нужны.
                    • +2
                      да, нет… просто много поработал над крупными проектами… в которых в шаблонах было такое, разбираться в чем врагу не пожелаешь… А начиналось все невинно с небольшого кода… Проект растет и развивается, и через некоторое время смарти начинает выигрывать и по чисто те кода и по его понятности для того кто поддерживает…
            • +1
              А почему не так?
              <?=isset($item['key']) ? $item['key'] : 'default'?>
              

              А если говорить не о наличии индекса в массиве, а о ненулевом значении, то ещё проще (PHP 5.3)
              <?=$item ?: 'default'?>
              
              • –3
                А почему не так?
                <?=isset($item['key']) ? $item['key'] : 'default'?>

                Пример взят из реального проекта и там между ?> и <? еще что то HTMLное вставлено… поэтому так как я записал!

                А если говорить не о наличии индекса в массиве, а о ненулевом значении, то ещё проще (PHP 5.3)
                <?=$item ?: 'default'?>

                Эх…
                Пример взят из реального проекта — И там нужно было выводить элемент массива и проверять его на существование. и при отсутствии вывести значение по умолчанию…
                Вы задачу то не подгоняйте, под любимый метод решения, не подгоняйте, плохая это практика!
                • +1
                  Разве я подгоняю? Как раз наоборот, этим занимаетесь вы.
                  Запись без шаблона — <? if (isset($item['key']):?> <?= $item['key'] ?> <? else: ?> default <?endif ?>
                  тоже самое в смарти — {$item.key | default:'default'}

                  Почему-то в примере на PHP у вас между ?> и <? еще что то HTMLное, а в примере на смарти ничего.
                  • –3
                    Ок значит вру…
                    Вы все свои проекты трехлетней давности помните?
                    Код для примера выдернул из письма по проекту… Если упереться то я думаю я найду и шаблон в архивах и причину почему там столько угловых скобок… Если оно конечно мне станет надо))))
                    • +1
                      Да что ж вы так злостно реагируете?
                      Я прекрасно представляю, как может выглядеть код с шаблонизатором и без него.

                      Если вы обратите внимание, я прокомментировал ваш конкретный пример, а не целесообразность использования смарти вообще. Если в вашем примере между ?> и <? должно быть что-то ещё, то исключительно ради честности следовало бы привести аналогичный пример на смарти:
                      {if $item.key} {$item.key} {else} default {/if}

                      Вообще я предлагаю не становиться заложником инструмента, а понимать насколько он уместен в каждом конкретном случае.
                • 0
                  isset это не проверка на ненулевое значение. Прежде всего это проверка на то, что переменная вообще существует, без появления нотайса, если не существует. В вашем примере получим нотайс «Undefined variable», если переменная не определена. Вообще из-за этого конструкция $var ?: 'default' бесполезна практически :(
          • 0
            Где-то в доках смарти было написано: наиболее частой ошибкой начинающих разработчиков является смешивание логики и представления.
          • +2
            Вообще-то PHP был когда то написан как язык шаблонов для perl…

            То есть писать шаблоны на PHP вполне логично. Но потом он развился… и теперь можно сделать на нём слишком много. И это есть причина почему настоящие собаководы рекомендуют использовать шаблонизаторы. А между строк читаем — «шаблоны предназначены для того, чтобы сузить функциональность, и защитится от криворуких верстальщиков, которые пишут спагетти-г… код»
            • –3
              Где то мне попадались тесты, код скомпилированный смарти иногда обгоняет код написанный руками по быстродействию, из за использования более быстрых конструкций языка, или как минимум не отстает.
              А жуткая мешанина php лапши в шаблонах зачастую мешает читать шаблон, да и постоянно кто то из «молодых» пытается вынести все в шаблон вплоть до запросов к базе данных, вычесывание такого кода. замедляет общий процесс разработки.
              • 0
                http://www.raintpl.com/PHP-Template-Engines-Speed-Test/
                Тут тесты смарти, php и еще каких-то шаблонизаторов.
                • 0
                  Строка из статьи:
                  echo '<option ...>'.$node['name'].'</option>';

                  Как можно ускорить эту строку… в несколько раз?)))) А заодно и сильно уменьшить потребление памяти в операции?
                  • 0
                    Не нашел где это. Но собственно ссылку привел для того что бы показать что native php будет быстрее.
                    Но при использовании кеша в смарти есть вероятность что смарти будет быстрее. (если к примеру в шаблоне будут какие нибудь вычисления :) )
                    • 0
                      Ну собственно я и про это кстати тоже))))
                    • +2
                      echo '<option ...>', $node['name'], '</option>';
                      • 0
                        Верно)))) Только вот в реальном проекте у любителей «шаблонов на чистом php» я за десять лет такую запись встречал ОДИН раз… Все через точку стараются сделать… а не через запятую…
                      • 0
                        Вы опять лукавите. Откуда возьмётся «в несколько раз»?

                        Проведите эксперимент:
                        $start = microtime(1);
                        ob_start();
                        for($i=0; $i<1000000; $i++) echo 'a' , $start , 'b';
                        ob_end_clean();
                        die(microtime(1) - $start);
                        

                        У меня получились такие результаты:
                        точка — 0.99 сек
                        запятая — 0.91 сек
                        «a{$start}b» — 1.0 сек
                        sprintf — 2.0 сек

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

                        В пользу записи через точку могу привести пример.
                        При рефакторинге потребовалось заменить вывод echo 'some' . 'string' на присваивание значения переменной $var .= 'some' . 'string'. Как вы понимаете мне достаточно было заменить «echo» на "$var .=", не выискивая запятые, т.к. она не является оператором конкатенации.
                        • 0
                          Вообще-то для более честного результата мне следовало делать замер времени внутри функций буферизации, но после проверки оказалось, что это влияет несущественно )
                          • 0
                            Для более честного результата стоило взять размеры коктенируемых значений более близкие к реальным, если мне не совсем отшибло память, давно с работой интерпретатора разбирался, то скорость падает с увеличением размера переменных, как и объем занимаемой памяти увеличивается тоже с ростом размера.
                        • 0
                          echo join( array( '<option ...>',$node['name'],'' ) );
                          На больших строках сравните. Разница бывает в сотни раз ;)
                          • 0
                            С объединением через точку согласен, А вот вывод через запятую сдается мне будет всетаки быстрее…
                        • 0
                          Да, RainTPL — отличный шаблонизатор. Всего один небольшой php файл, а может практически тоже самое, что монстр Smarty, по крайней мере все мои нужды покрывает. Я чуть допилил его для себя и с удовольствием пользуюсь уже пару лет.
                          • 0
                            Верю, что он покрывает Ваши нужды, но утверждать, что он «может практически тоже самое, что монстр Smarty», мягко говоря, некорректно. Навскидку не вижу таких вещей, как расширяемость с помощью сторонних компонентов (функций/фильтров/модификаторов), кеширования скомпилированных шаблонов, наследования шаблонов — вещи, которые, с моей точки зрения, и придают шаблонизаторам особую ценность.
                      • 0
                        Во-первых MVC и все такое, так что лучше разделять логику и представление, и вообще если у вас в шаблоне что-то сложное, значит что-то вы делаете не так в логике контроллера.
                        Во-вторых пожалейте верстальщиков, которым намного легче выучить простые 5 конструкций шаблонизатора, чем смотреть на ваш PHP код.
                        • +16
                          Как будто попал лет на 8 назад.
                          • +2
                            У меня есть один проект где смарти и код хранится в бд, php код в бд это особенно меня радовало, когда я только начинал с ним разбираться ищешь поиском на диске нужный код, а его нет.
                            • +12
                              А теперь к потребностям шаблонов.
                              Автоэкронирование html, js, css
                              Наследование, кэширование блоков, переопределение блоков.
                              Буферизация, тримминг, вырезание лишних пробелов и т.д.
                              Итерации — первая, последняя, вывод в две колонки

                              Давайте скажем проще, вы никогда не использовали смарти, а просто заменили свои ## на {{}}, так что и с переходом вы ничего не потеряли.

                              • +6
                                Кажется, примеры специально подобраны, чтобы показать, какой страшный Smarty и какой приятный pure php.

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

                                {$var|escape 'html'|upper} против <?= htmlspecialchars(strtoupper($var));?> или даже <?php echo  htmlspecialchars(strtoupper($var));?>
                                


                                Smarty 3 давным-давно «умеет» более простые объявления переменных и прочую математику, мучаться с assign уже не обязательно:

                                {$var = $a + $b;} против <?php $var = $a + $b; ?>
                                


                                Про рекурсивное дерево — {function} уже упомянуто выше.

                                И странное утверждение о том, что Smarty должен быть удобнее для дизайнеров — дизайнеры обычно только рисуют, а html-код готовят верстальщики, а не дизайнеры. И им гораздо проще разобраться в Smarty и его возможностях, чем изучать язык PHP, чтобы понять, что навернуто в шаблонах. А если программист отвечает еще и за верстку — то это вопрос к организации процесса, а не к Smarty.

                                Я использовал pure php в шаблонах и лично мне очень не нравится мешанина из <?-тегов, в которые это в итоге выливается (что еще и читаемость затрудняет — труднее отделить визуально html-тэги от php-тэгов):

                                Smarty:
                                <table>
                                <tr><th>{'Header'  |  i18n | escape 'htmlall'}</th><th>{'Name'  |  i18n | escape 'htmlall'}</th></tr>
                                {foreach $table as $row}
                                <tr><td>{$row.header | escape 'htmlall'}</td><td>{$row.name | escape 'htmlall'}</td></tr>
                                {/foreach}
                                </table>
                                


                                То же самое на php:
                                <table>
                                <tr><th><?=  CHtml::encode(Yii::t('', Header' )); ?></th><th><?= CHtml::encode(Yii::t('', 'Name')); ?></th></tr>
                                <?php foreach($table as $row) { ?>
                                <tr><td><?= CHtml::encode($row['header']); ?></td><td><?= CHtml::encode($row['name']); ?></td></tr>
                                <?php } ?>
                                </table>
                                

                                • 0
                                  Вот где ад pastebin.com/ypahcSYf, слабонервным не смотреть.

                                  А у вас слабенькие примеры.
                                  • +4
                                    Ад? Откройте любой шаблон битрикса.
                                • –5
                                  Любой мало мальский дизайнер или просто хорошший программист запустит вам в лицо крайне тяжелым предметом если увидит в файлах шаблонов — пхп код.

                                  А по поводу смарти — вы просто не умеете его готовить. Совсем.
                                  • +4
                                    Глупость говорите.
                                  • –1
                                    Да что уж там:
                                    Проще? Нет.
                                    Понятнее? Нет.
                                    Быстрее? Возможно.
                                    Безопаснее? Нет.

                                    А если еще и взять вместо smarty нормальный шаблонизатор…
                                    • 0
                                      А какой нормальный, на Ваш взгляд?
                                  • 0
                                    Вы наверное не используете наследование в шаблонах, раз говорите что голый php лучше?
                                    • 0
                                      Наверное вообще в шаблонах ничего не использует
                                    • +6
                                      Гос-ди б-же, какой смысл в этой статье? Что автор хочет донести до нас?
                                      • +5
                                        Что автор хочет донести до нас?

                                        То, что 2-3 года назад перестал использовать Смарти
                                        • +6
                                          Ясно. Надеюсь будет держать в курсе и дальше.
                                          • +4
                                            Ждем статьи о том, как автор ушел с php 5.2
                                        • –1
                                          Прежде всего я хотел рассказать тем, кто только начинает писать: не стоит хвататься за что-то, без чего можно обойтись (как в моем случае), как бы это ни казалось круто и модно. И больше думать, что даст та или иная технология проекту и вам лично.
                                          • 0
                                            То что он отстал в технологиях лет так на 10
                                          • 0
                                            Верстальщик. Использую Smarty больше 5 лет, нравится, доволен, отлично разделяется логика от представления. Все доводы против прочитал, спасибо, но не надо. Мне кажется тот, кто пишет php код в шаблонах попросту многостаночник — архитектор, дизайнер, программист, верстальщик в одном лице. Ему наверное проще. Кстати, MVC тоже прекрасно пишется в одном файле.
                                            • +3
                                              Даже в простых вещах, как вывод значения переменной не знаю как в смарти, а в твиге все очень круто сделано.

                                              {{ user.status }}
                                              

                                              Тут твиг пройдется по стеку возможных использований: массив, объект с открытым полем, геттер. Если такая конструкция используется в условии — проверит has/is.
                                              А еще фильтры… В php не все объекты, так что user->getStatus()->ucfirst() не получится. А что если нужно использовать несколько функций? А как разделить логику получения свойства от логики ее изменения? В шаблоне все четко понятно:

                                              <?= ucfirst(e($user->getStatus())); ?>
                                              
                                              {{ user.status | e | capitalize  }}
                                              
                                              • +1
                                                Согласен. Сам был раньше сторонником «чистого PHP» в шаблнах, но понял что все мои беды были не от шаблонов, а от Smarty =) Перешел на Twig и полюбил шаблоны :)

                                                Банальный пример — с чистым PHP — данные (например дату отформатировать) нужно для вывода либо подготавливать в логике, либо писать уродливые длинные вызовы функций со скобками в шаблонах…
                                                • 0
                                                  Да и «чистый PHP» по умолчанию не будет «чистым», потому что какой-никакой свой шаблонизатор навертеть вокруг шаблонов нужно — хотябы чтобы все переменные по умолчанию ескейпились, что облегчает работу, скокращает код/улучшает читабельность и по умолчанию повышает секьюрность, так как проескейпить переменную можно просто забыть. Твиг и новый Смарти (вроде) делают это по умолчанию.
                                                  • 0
                                                    Твиг является наследником смарти, поэтому в смарти точно так же, только синтаксис чуть-чуть отличается: {$user.status}, {$user.status|@e|@capitalize}
                                                    • +1
                                                      Громко называть twig наследником смарти)
                                                      Twig uses a syntax similar to the Django and Jinja template languages which inspired the Twig runtime environment.

                                                      Тот факт, что синтаксис схож говорит лишь о том, что это удобный синтаксис, стандарт дефакто)
                                                    • 0
                                                      напоминает синтаксис шаблонов Django =) Попробовать что-ли=)
                                                    • +2
                                                      а еще в смарти есть кеширование, что часто нивелирует преимущество чистого пхп шаблонизатора чуть более чем полностью. Впрочем никто не мешает и для пхп шаблонизатора сделать кеширование.
                                                      • +2
                                                        twig vs native php:

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

                                                        Если мы посмотрим на скомпилированные шаблоны твига, то увидим что код в них написан максимально оптимально (хоть зачастую и нечитаемо совсем). Те же блоки — просто методы класса, поэтому наследование — шаблонов — обычное нативное наследование классов в php. Ввиду изложенного мы понимаем что твиг как минимум не проигрывает в скорости нативному php.

                                                        Мой выбор — твиг.
                                                        • 0
                                                          Какое винтажное решение однако. По мне так если в HTML шаблоне находиться что-то кроме HTML, ну и максимум каких-то флагов, вроде {VALUE}, то это уже нарушение MVC. Внутри шаблона не должно быть условий, ветвлений и преобразования типов. Если что-то такое там есть, то верстальщик всегда может поломать логику и пойдет игра в тяни-толкай, когда одни правят баги логики, вторые фронт-енд и так до упора, по кругу.
                                                          Под мои принципы подходят самые простые варианты, вроде: www.phpxtemplate.org/ (сам юзаю самописный парсер, но синтаксис почти 1 в 1 как XTemplate)
                                                          • +1
                                                            Внутри шаблона не должно быть условий, ветвлений и преобразования типов

                                                            Спорно. Надо вывести табличку под данным — вот уже цикл есть. Надо табличку раскрасить в разные цвета по строкам для лучшей читаемости — вот уже и ветвление (это точно не задача контроллера или модели в MVC), а еще форматирование данных при выводе и тому подобное.
                                                            • –2
                                                              Чтобы вывести несколько строк внутри таблицы, секция с шаблоном строки задается один раз, иначе будет нарушение не только MVC, но и DRY, раскрасить в разные цвета можно через переменную (надеюсь сообразите сами как, теги не работают, чтоб пример написать), за то, сколько раз строку рисовать отвечает логика, а не шаблон. Конечно можно намешать HTML с PHP или псевдоязыком парсера, формально не нарушая MVC, но я не просто так описывал, что дело помимо прочего в разделении доступа \ зоны ответственности верстальщика и программиста.
                                                              Форматирование я выношу в логику тоже, конечно хочется чего-нить такого дописать, чтоб хотя бы строки экранировало, да даты через конфиг менялись, но ничто не мешает добавить умный флаг, в назначение значения со стороны логики, сложнее не станет, а чистота шаблона сохранится.
                                                              • 0
                                                                Чтобы вывести несколько строк внутри таблицы, секция с шаблоном строки задается один раз

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

                                                                раскрасить в разные цвета можно через переменную (надеюсь сообразите сами как, теги не работают, чтоб пример написать),

                                                                Не сообразил. Напишите как. Напоминаю исходные условия: в шаблонах ветвлений нельзя, условий нельзя. Части model и controller за отображение не отвечают никак. Как именно в таких условиях обеспечить раскраску строк таблицы?

                                                                за то, сколько раз строку рисовать, отвечает логика, а не шаблон...

                                                                WAT? Логику в идеале вообще не должно волновать, как именно ее данные там рисуют.

                                                                Проверьте свои рассуждения таким образом. Возьмите проект и решите, что теперь мы будем возвращать не html, а, например, json. Если в коде частей model и controller при этом что-то надо менять (или удалять), то что-то не так (с определенными оговорками, конечно, но тем не менее). Лично я не вижу ничего плохого в том, чтобы логику отображения писать непосредственно в этом отображении.
                                                                • 0
                                                                  Еще раз обращу ваше внимание, что я делю проект на логику и шаблоны, не как понятия модель-представление из MVC, а как практические сферы для программиста и для верстальщика (а то и вовсе девушки секретарши, которой надо быстрый хотфикс сделать по требованию босса). Таким образом если вы возьмете XTemplate например — сам класс его будет называться не представлением, а логикой, а шаблон, это HTML файл который передается для создания объекта, с этой стороны тест на формальный MVC не будет пройден, потому что если нам надо будет генерить json, то изменения затронут XTemplate (или его наследника), а мы их обозвали логикой. Если вы хотите придерживаться MVC терминологии — пожалуйста, но внутри представления тогда должно быть еще одно деление, на логику-представления и HTML шаблон.

                                                                  Главная мысль в том, чтобы максимально отчистить шаблон, сделав его безопасным для редактирования пресловутой секретаршей, как-то так это выглядит в синтаксисе XTemplate:
                                                                  jsfiddle.net/2FWpU/3/
                                                                  (В JS секцию код на PHP я запихал)
                                                                  Спорный момент там в том, что имя CSS класса для раскраски приходиться в логику пихать, но это на мой взгляд меньшее зло.
                                                                  • 0
                                                                    Шаблоны в MVC в наименьшей степени предназначаются для секретарш. То что вы описываете, это компонентная система, прямо противоположная MVC. Там в шаблонах вставляются компоненты, у которых можно задавать разные характеристики и да нет циклов и да, легче для секретарш. Но это не MVC, хотя внутри компонент может содержать эту архитектуру.

                                                                    А компонентная система слишком громоздка и затормаживает разработку, поэтому ее используют в основном в CMS для не специалистов.
                                                                    • 0
                                                                      Не знаком с таким термином, гугл тоже не в курсе, по запросу «компонентная система» что-то там про колонки вешает. Компонентная архитектура тоже не о том, ее можно еще как-то к фронтенду применить, но у нас речь именно о серверной части и в HTML мы никакую привязку к событиям не делаем, так что компонентами их назвать нельзя.
                                                                      Так или иначе, не соглашусь, что подобный подход затормаживает разработку. В моей практике реально, случаев, когда очень уж сильно хочется условный оператор зафигачить в шаблон 1% от всего проекта, а лет через 5 подобной практики даже это редкое желание уходит. В то время как от Smarty-подобных подходов жжение от батхерта в процессе дебага и поддержки у меня только увеличивалось год от года.
                                                                      Впрочем я не претендую на истину в последней инстанции, возможно это связанно со спецификой моих проектов и заказчиков (последние расселены от Штатов до Австралии, что провоцирует острое желание научить их самих делать хотфиксы, а не будить меня по ночам, если нужен какой-то срочный апдейт фронтенда).
                                                                      • 0
                                                                        Ну компонентная система это абстрактное понятие, когда система состоит из кусочков, которые можно собирать воедино, как конструктор. Не обязательно компонент может быть основан только на событиях. Но принцип в том, что в шаблон вставляется компонент, который пользователь может конфигурировать, т.е. менять его параметры. В параметр компонента может даже входит какая-то часть шаблона, например список новостей, а у него есть мини-шаблон-параметр для выводя элемента новости и т.п., есть параметр кол-во новостей на странице. Да циклов нет, условий нет, вся логика скрыта внутри компонента. Конечно, желательно конфигурирование шаблона должно быть в гуи.
                                                          • 0
                                                            Включение чистого PHP в Smarty.
                                                            Уж коли он по какой-то причине нужен. Иными словами да здравствуют холивары…
                                                            Smarty — примерно такая же обёртка над PHP, как jQuery над JS. Абстракция. Хочешь — используй, не хочешь — не используй.
                                                            Привет основной теореме программной инженерии.

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