Пользователь
0,0
рейтинг
30 октября 2013 в 17:13

Разработка → Почему я отказался от использования Smarty из песочницы

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

Когда я пришел на работу в одну американскую контору (удаленно конечно. и было это году так в 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, и потому текущее состояние дел мне оценить сложно, но думаю дела обстоят не лучше и не хуже чем было раньше.
Андрей Мурин @96467840
карма
3,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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
        Да хоть вариации одного и того же: Twig (php), Jinja2 (python), twig.js (javascript).
        • 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. Абстракция. Хочешь — используй, не хочешь — не используй.
    Привет основной теореме программной инженерии.

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