Зачем нужен Smarty

Фанат

oncle terrible
Команда форума
Не, ну что где есть - это неинтересная информация.
Интересны примеры, сравнения. Сложные примеры реальных задач и адекватные сравнения, а не "вот у вас такой говнокод (пишется намеренный говнокод), а у нас такая няшечка (пишется сферическая няшечка в вакууме)"
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Я не строил сравнения «у вас - говно, у нас - няшечка»
Я просто считаю, что писать что-то, уже имеющее готовую приемлемую реализацию — Сизифов труд.
 

Фанат

oncle terrible
Команда форума
А я и не обвинял тебя в том, что ты строил сравнения. Совершенно не за что оправдываться.
Я приводил пример хорошего поста по теме.
"Приемлемая реализация" - это пример плохого поста. Решние описанной задачи было бы интересно. Просто писать "твиг - няшечка" - нет.

Сравнивать в данном случае - твиг и нейтив. Можно не сравнивать. Можно написать только свою часть.
Важно не сравнение. Важно писать предметно.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Надо сказать, что пишу я сам преимущественно шаблоны на нативном пхп сейчас.
С моей точки зрения, проблема «шаблоны на пхп против шаблоны со своим синтаксисом» довольно надумана, ну или хотя бы неоднозначна — потому что, это по факту одно и то же, и с таким же успехом можно спорить что лучше, руби или пхп.
У отдельного языка шаблонизации, с моей точки зрения, есть плюсы в виде естественного разделения логики приложения с логикой отображения, а нативные шаблоны в данном случае очень соблазнительны в плане появления у неопытных программистов мыслей типа «ну я щас тут быстренько всего лишь один запросик к базе сделаю, ничего же не будет». Другим моментом является то, что нет «чистых шаблонов на нативном пхп» если только вы не пишете это все без общей точки входа в index.php, a в стиле «одна страница - один файл» — иначе вам все равно приходится писать обертки, хелперы, перехватывать вывод, следить за областью видимости переменной — поэтому «пхп это шаблонизатор» в большинстве случаев — не правда. Хотите двухпроходный шаблон с общим родительским шаблоном? Вы все равно будете писать шаблонизатор, пусть даже и с нативным синтаксисом.
Поэтому я просто слабо представляю себе, как их сравнивать — по-моему, это одно и то же, в конечном итоге.
 

Фанат

oncle terrible
Команда форума
Опять же, я не призываю спорить.
Я призываю приводить примеры решений.
Хотите двухпроходный шаблон с общим родительским шаблоном? Вы все равно будете писать шаблонизатор, пусть даже и с нативным синтаксисом.
Будем. Вот мне и интересно решение поставленных задач.
Или обоснование, почему это будет велосипед на кривых колесах. Не голословное утверждение, а предметный разбор.
В частности, если делать двухпроходник, то смысл делать нейтив сразу улетучивается. Но можно ведь попробовать и без!

Я полагаю, что если человек уже сталкивался с подобной задачей - он сможет сделать её разбор.
Ели не сталкивался, но она ему интересна - он может поучаствовать в мысленном эксперименте

А говорить "твиг это все умеет" - это, извините, то же самое, что "для защиты от инъекций все входящие данные надо искейпить" - императив с сомнительной истинностью, предназначенный для быдлокодеров, которые живут не умом, а инструкциями. (Надо снова пояснять, что это не персональный выпад, а описание явления?)
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Или обоснование, почему это будет велосипед на кривых колесах.
Кто — двухпроходной шаблон? Или написанный шаблонизатор?
Я на самом деле исхожу из количества и качества приложенных для его появления ресурсов. Для меня очевидно, что некоторый уже существующее готовое решение, за авторством человека, опытного в архитектурных программных решениях, с немалым сообществом, которое тестирует его в различных ситуациях, которое получает регулярные обновления, заведомо лучше того, что мог бы написать я сидя вечерами. С этой точки зрения любой «самопис» будет с кривыми колесами.
Если рассматривать с точки зрения получения личного опыта, игнорируя чужой (на котором известно кто учится) то никакой готовый шаблонизатор не идет в сравнение с отдачей опыта от написания самому :)
 

Духовность™

Продвинутый новичок
У отдельного языка шаблонизации, с моей точки зрения, есть плюсы в виде естественного разделения логики приложения с логикой отображения
http://phpclub.ru/talk/threads/Два-вопроса-по-недошаблонизатору-blitz-или-наглядно-о-том-какие-не-должны-быть-шаблонизаторы.69567/
 

ksnk

прохожий
И что будет "правильным" результатом?
К примеру класс с парой методов
-- init, в котором перечислены init'ы всех присутствующих в шаблоне классов-шаблонов.
-- render, который по полученным данным строит нужный html
будет решением?

Отчего бы такой класс не построить по какому-то шаблону с twig(Django) синтаксисом?
 

С.

Продвинутый новичок
нативные шаблоны в данном случае очень соблазнительны в плане появления у неопытных программистов мыслей типа «ну я щас тут быстренько всего лишь один запросик к базе сделаю, ничего же не будет»
Предлагаю из всех дискуссий в клубе о шаблонизаторах этот тезис запретить на уровне правил. Он не имеет никакого отношения к реальной жизни. Да, есть люди, которых нельзя подпускать к программированию ближе чем на расстояние оглобли. Но такие очень быстро выявляются и отфильтровываются, прежде чем они успевают наставить обращений к базе в шаблоне. Тем более, что "кучерявый" шаблонизатор тут не спасет, они могут поставить этот вызов и в контролере или в другом самом неожиданном месте. Мы уже обсуждали тему, что на самом деле граница между М, В и Ц размыта, и не всегда однозначно можно сказать, к чему относится определенная функциональность -- к логике модели или логике вью? Даже среди доскональных профессионалов будет разное мнение, куда ее воткнуть. А вы тут про запросы к базе в шаблоне... Фу! Какая пошлость.
 

Period

Новичок
Ну, это полная фигня, упоминания явно не стоила.
Конечно:
PHP:
<? if (count($category_tree)): ?>
    <? foreach($category_tree as $category): ?>
        <?= $category->name ?>
    <? endforeach; ?>
<? else: ?>
    No items in tree
<? endif; ?>
против

PHP:
{% for category in category_tree %}
    {{ category.name }}
{% else %}
    No items in tree
{% endfor %}
фигня полная. одно и тоже. И это ещё с шорт-тегами, а могло быть куда ужаснее, но это уже другой холивар. Верстальщики точно спасибо не скажут.

А вот здесь хотелось бы поподробнее.
Очень желательно - с примером.
Шаблон index.html
PHP:
<html>
    <head>
        <title>{% block head_title %}Название сайта{% endblock %}</title>
    </head>
    <body>
        {% block content %}{% endblock %}
    </body>
</html>
Шаблон article.html

PHP:
{% extends "index.html" %}

{% block head_title %}Название статьи{% endblock %}

{% block content %}текст статьи{% endblock %}
при выводе шаблона article.html получается
PHP:
<html>
    <head>
        <title>Название статьи</title>
    </head>
    <body>
        текст статьи
    </body>
</html>
Это простенький пример. Возьмите случаи, когда для одной страницы нужно использовать какие-нибудь тяжёлые JS-библиотеки, а для другой - нет. Раньше это либо жуткими проверками достигалось, либо пути к требуемым JS приходили из PHP-кода. Теперь каждый шаблон может неограниченно влиять на всю страницу. В любом месте прописывать всё, что ему нужно.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Period
еще про сохранение содержимого упомянуть можно, типа

PHP:
{% extends "index.twig" %}
{% block content %}
Some new content
{% parent() %} // содержимое блока content из вышестоящего шаблона
{% endblock %}
 

Вурдалак

Продвинутый новичок
Стоит отдельно отметить, что тут:
PHP:
<? if (count($category_tree)): ?>
    <? foreach($category_tree as $category): ?>
        <?= $category->name ?>
    <? endforeach; ?>
<? else: ?>
    No items in tree
<? endif; ?>
отсутствует htmlspecialchars. Это как pure SQL без prepared statements. Жить можно, но грустно.

Наследование шаблонов, справедливости ради, реализовано в вышеупомянутом pure PHP-аналоге Twig'а.

P.S. http://fabien.potencier.org/article/34/templating-engines-in-php — кому-то интересно мнение автора Twig'а? Если кратко, то pure PHP-шаблоны страдают а) многословностью и б) отсутствием чёткой грани между тем что нужно оставить в шаблоне, а что выносить, Twig помогает держаться в рамках и делать всё более лаконично. Jedem das Seine. ;)
 

Фанат

oncle terrible
Команда форума
PHP:
<? foreach($category_tree as $category): ?>
  <?=$category->name ?>
<? endforeach ?>
<? if (!$category_tree): ?>
    No items in tree
<? endif ?>
Да, на одну строчку больше. Зато и читабельность повыше.
И двайте заодно с неумением разделять логику запретим приплетать " бедных верстальщиков". придет такой хоть один - будем ему сочувствовать. А пока это воображаемый страдалец в вакууме, служащий исключительно для патетических восклицаний, на его упоминание наложим запрет.

На этом тему субъективных ощущений предлагаю закрыть

PHP:
{% extends "index.html" %}
А вот это выглядит заманчиво.
 

Фанат

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

Автор Twig'а как раз такой шулер, о котором я говорил - в пыхе у него выбирается самый уродский вариант.
Шулера не понимают, что таким образом они подрывают доверие к своему продукту в целом. Неужели нету честного способа доказать превосходство, обязательно надо жучить?
 

Вурдалак

Продвинутый новичок
Вот как раз для этого и нужен класс View. Который будет по умолчанию искейпить все входящие переменные, за исключением тех, о которх ему было сказано особо.
Атрибуты object'ов тоже экранируешь (всё тот же пример выше)? И как?
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Читабельность не выше, писабельность — тоже.
 

Фанат

oncle terrible
Команда форума
Вурдалак
Ну, по-хорошему, я бы не стал передавать объекты в шаблон вообще.
Им там, в общем-то, нечего делать.
Я бы передавал массивы и скаляры.
 
Сверху