Ну вот отсюда все и идет. Вобщем то шаблонизатор, это не инструмент верстальщика. А программисту (пусть фронт-эндеру) может быть удобно использовать его, а может и нет. Все зависит от организации процесса. Но своё святое предназночение (отделить верстку от логики) он не выполняет и верстальщику, как таковому, жизни не облегчает точно.

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

Так что все хорошо на своем месте.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

С точки зрения HTML лишние пробелы вообще игнорируются.

_____________
Gear Framework
Gear Framework на Github

Ну, как минимум Википедия...

А вообще это первый довод приверженцев в подобных холиварах. Я в них раньше часто со всем пылом и жаром участвовал.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Это хорошо, если программер и версталь договорились, что в шаблон пойдёт unix-timestamp, а если программер изменил код или изменил в таблице тип столбца. Должны быть чёткие договорённости и самая тесная связь версталь-программер, один должен помнить, что версталь требует unix-timestamp, а версталь должен вникать в работу программера, чтобы знать кому вставить пистон, если вместо даты фигня выводится. И таких

полно.

_____________
Gear Framework
Gear Framework на Github

Не всегда, есть вариант, когда в шаблонах вообще нет логики. Никакой. Я как раз такую схему использую. :)

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

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

Да, шаблонизаторы с тех пор, дабы хоть как то оправдать свое существование, обросли всякими фишками и приблудами плана компиляции, кэширования, наследований, всяких макросов и прочая-прочая. Собственно перетянули на себя одеяло, взяв часть функционала PHP. Кому то это кажется удобным, кому то нет, спорить глупо. Всё зависит от "воспитания". :) Собственно это уже не вызывает споров, теперь шаблонизаторы позиционируются как "удобные" инструменты, позволяющие то, сё и многое другое.

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

А вот что ни говори, PHP может все, что может шаблонизатор. Но не наоборот. Да просто потому. что сами шаблонизаторы на PHP и написаны.

Документация - ну да. Большой плюс. Как и защита от дурака... Наверняка это очень полезно при текучке и низкой квалификации кадров. Тут спорить глупо, это реальное подспорье.

Опять же как построен процесс и как эти самые кадры используются.

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

<table width="50%" height="200px" border="1">
{% for row in items|batch(3, ' ') %}
    <tr>
        {% for column in row %}
            <td>{{ column }}</td>
        {% endfor %}
    </tr>
{% endfor %}
</table>

а потом такой:

<table width="50%" height="200px" border="1">
<?php for(...){ ?>
    <tr>
        <?php for(...){ ?>
            <td><?php $column ?></td>
        <?php } ?>
    </tr>
<?php } ?>
</table>

Не, я конечно понимаю, сейчас вы скажите, да кто мол будет открывать шаблон по физическому пути? А вот как раз верстальщики именно это зачастую и делают. Верстальщики, повторюсь. У которых и сервер то не всегда есть за ненадобностью. Ибо верстка, это статика. Газета. Трекинг и кернинг.

Так вот одна из фишек нативного синтаксиса это то, что вот это: <?php ?> - обычный тег. И браузер его на экран не тащит и на верстку они не влияют. А значит верстальщику проще поправить верстку, ему эти логические вставки практически не мешают. В отличие от.

Но конечно, если версткой занимаются программисты (пусть фронт-эндеры, не суть), тогда на это не стоит обращать внимания. Они пользуются тем, к чему привыкли. Так же, как и к фреймворкам и многим другим приблудам, которые вызывают столь бурные дебаты.

Еще раз говорю, хороша ложка к обеду. Кому то это кажется круто, кому то излишеством и геморроем. Каждый прав по своему.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.