Немного подзадолбался городить такую чушь. Думаю, пора уже заняться выпрямлением своих рук и облагораживанием кода, дабы не слыть быдлокодером. Хочу отделения логики от верстки с максимально кратким синтаксисом в шаблоне и ничтожными затратами производительности. Посмотрел Smarty - чот не особо впечатлило, по-моему он мало чем отличается от простого PHP внутри HTML. Тут какой-то Mustache нарисовался - кто-нибудь пробовал? В общем, прошу посоветовать самый удобный шаблонизатор на ваш взгляд.))
Вообще, шаблонизатор прежде всего отличается отсутствием логики в конечном представлении. Т.е. где-то у нас произведены все запросы/расчеты, а тут чисто вывод уже, подстановка значений в переменные. Тут php действительно и сам по себе неплох, если не городить мешанину, но блин: Код (Text): {foreach $array as $key => $row} {if $row@first}тут начало массива{/if} {$key} - {$row} {if $row@last}тут конец массива{/if} {foreachelse} пусто же {/foreach} удобно же )
Код (PHP): if (!empty($array)) { тут начало массива foreach($array as $key=>$val){ {$key} - {$val} } тут конец массива } else { пусто же }
Есть системы поддержки шаблонов, а есть язык разметки шаблонов. Можно писать "нативные" шаблоны на PHP, но при этом пользоваться неким классом, облегчающим типичные для Представления операции. Например в составе Symfony 2 есть Symfony Templating Component и в нём, как вариант шаблонного движка, присутствует класс PhpEngine. Это как раз шаблонизатор без собственного языка разметки. Советую также обратить внимание на Plates.
Короче, надо брать что приглянется. Главное не выводить хтмлку через echo вперемешку с обращениями к бд и прочей обработкой одной большой простыней, а какой для этого использовать инструмент - дело вкуса и привычки. Ну и предполагаемой нагрузки: всё же нативный пхп как не крути, но быстрее )
twig Добавлено спустя 2 минуты 2 секунды: в симфоническом компоненте синтаксис корявый но это еще мелочи, а вот то, что нету механизма наследования блоков - это уже совсем не дело...
d1gi, не собираюсь никого агитировать, но очевидно ты не в теме. Синтаксис там не корявее самого PHP потому что это и есть PHP. Наследование и блоки присутствуют. Сейчас модно хвалить Twig. Я тоже присоединяюсь: синтаксис очень симпатичный, ведь это копия django templates. Если бы не чудовищный тормозной код в который он транслируется, я бы других и не искал.
artoodetoo, о благодарствую! странно, что в своё время просмотрел наследования и забил на пхп енджин а на счет "тормознутости", у вас прям проект упирается в твиг? еще вспомнил момент, в симфоническом шаблонизаторе есть метод аналогичный твиговскому {{ parent() }} ? т.е. отобразить родительский блок. igordata, потому что лаконично и удобно особенно наследования и блоки.
d1gi, не упирается. и не в twig ))) инструмент подбирается под задачу по совокупности параметров, а не за "красивые глазки". пример: форум fluxbb во многом хорош, но в нем представление не выделено из кода, шаблоны в зачаточном состоянии — я бы хотел это исправить. весь движок fluxbb это 150 файлов и 32тыс строк. а twig порядка 200 файлов и 9тыс строк кода. сравни цифры и ты поймешь, что twig просто несоразмерен этой задаче. с другой стороны, типичное приложение на symfony 2 со всеми бандлами (включая twig) начинается от 4тыс файлов и 250тыс строк кода (цифры из "Symfony Standard Edition"). тут уже можно потерпеть, правда?
Хорош: Код (Text): {% extends sonata_block.templates.block_base %} {% block block %} <div style="text-align: right; margin-bottom: 10px;"> {% if user %} <a href="{{ path('sonata_user_profile_show') }}">{{ user.username }}</a> | <a href="{{ path('fos_user_security_logout') }}">{{ 'link_logout' | trans({}, "SonataUserBundle") }}</a> {% else %} <a href="{{ path('fos_user_security_login') }}">{{ 'link_login'|trans({}, 'SonataUserBundle') }}</a> | <a href="{{ path('fos_user_registration_register') }}">{{ 'link_register'|trans({}, 'SonataUserBundle') }}</a> {% endif %} </div> {% endblock %}
PHP - шикарный шаблонизатор.)) Сейчас я вывожу всё в шаблон таким образом (точнее, я ввожу шаблон в PHP-код): Код (PHP): $content = file_get_contents($_P['root'].'portal/templates/template.html'); foreach ($_P as $key => $value) { $content = str_replace('{P_'.strtoupper($key).'}', $value, $content); } echo $content; Это позволяет мне использовать в шаблоне template.html любые строковые переменные из массива $_P в виде {P_ROOT} например. В общем, со строковыми переменными всё гуд, но в PHP меня огорчает вывод циклов в шаблон - тут либо кусочек логики приходится вставлять в шаблон, либо кусочек шаблона в логику. Это единственная причина, по которой я хочу попробовать шаблонизаторы. В идеале, в шаблоне должно быть написано что-то мега-краткое вроде: Код (Text): <ul id="#content"> {P_CYCLE_THIS_SHIT}<li><a href="{P_LINK}">{P_TEXT}</a></li> </ul> Мне скоро в офис устраиваться кодером, а значит буду работать в паре с верстальщиком. А значит нужно прекратить говнокодить и научиться отделять логику от верстки.
Я один такой странный, завожу для каждого компонента сопровождающий класс view (несколько, если есть разные варианты отображения), после чего просто опосля инициализации компонента вызываю new view($this), а вьюха уже сама разбирается, что от нее хотят, вставляет нужные данные в html и отдает клиенту? И не парюсь ни со смарти, ни с хренарти, ни с макаронными изделиями в коде. Логика при этом полностью отделена от представления. По крайней мере настолько, насколько это возможно. И все это на чистом пыхе и удобно для чтения/правок.
artoodetoo, а про твиговский метод {{ parent() }} в симфоническом шаблонизаторе что-нить скажешь? аналог есть? про "файлы и строчки" всё понятно правда!
ты спроси Фабьена Потенсье. мне parent в шаблоне не нужен. кстати, я считаю, что реализация перекрытия блоков в "унаследованных" шаблонах у твига сделана по говняцки. я бы объяснил, но кому это нужно?!
Код внутри родительского блока будет выполнен в любом случае — хоть он перекрыт в "наследнике", хоть нет. Если он переопределен наследником, то его результат будет перезаписан поверх и мы его не увидим. Но бесполезная работа полюбому была выполнена. EDITED 26.01.2014: не знаю откуда я взял это дерьмо, но я был неправ. может быть в какой-то старой версии так было или в оригинальном django templates… правда до сих пор никто меня не поправил. это говорит об уровне обсуждения ))) Сейчас у покопал нутро твига получше и мне по прежнему не нравится бессмысленная избыточность и тормознутость скомпилированного кода. Когда Фабьен говорит о "быстром" твиге, он козыряет скоростью компиляции, а это малоебучий фактор. По скорости исполнения готового кода он проигрывает даже Smarty.