Верстальщик не станет лепить |e к var зачем ему это, если он нифига не знает "плохо понимает всякие XSS", да и какой он нафиг автоматический, когда его нужно ручками прописывать

кстати по поводу наследования, есть ли в смарти/твиге принудительное отключение этой фичи? Ну что то типа $smarty->disable_extending() ?

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

Кто вам такое сказал? Вы не в курсе, что можно поставить хендлер на вывод? (правда оно не совсем то, но всё же варианты есть, как например работа с буфером вывода)

P.S. вы уже так говорите, как-будто шаблонизатор не на PHP написан я начинаю пужаться.

_____________
Gear Framework
Gear Framework на Github

Согласен, но это делает не контроллер, а его конкретный экшен, который совершает определённую функцию, и который должен знать куда пойдёт вывод, ибо

шаблонизатор не решает будет ли это вывод html или вывод в json. На выходе шаблонизатора тоже обычные данные, которые сформированы по указанному шаблону, и этот шаблон указывает именно контроллер/экшен, а раз так, то экшен в том числе знает какие данные пойдут в шаблонизатор и для чего.

_____________
Gear Framework
Gear Framework на Github

А все ли данные нуждаются в эскейпинге?

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

_____________
Gear Framework
Gear Framework на Github

Это определяется параметром в GET или POST запросе, или контроллером или экшеном, вариантов масса. Определение формата вывода - не магия и не телепатия.

А бизнес-логика в этом случае куда пихается?

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

_____________
Gear Framework
Gear Framework на Github

Делают. Еще как. И плевать им на циклы, они делают разные варианты, если это принципиально. Я говорю о верстальщиках, о тех, кто гораздо ближе к фотошопу, чем к серверу.

У вас нет верстальщиков, вы работаете исключительно с программистами. От того вам и люб шаблонизатор. И это ваше право, увольнять своих работников или переучивать.

У нас такое не канает. Верстальщику работать с данными некогда. Ему бы макет успеть сверстать. И шаблонизатор ему ну никуда не уперся. А уж фронт-энд программисту с готовым макетом тем более. И ему нафиг не нужны все эти эскейпы, наследования и прочая муть в шаблонизаторе. Ему привычнее работать с PHP.

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

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

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

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

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