[x-yuri]

Если тег валится с ошибкой (например, некорректное JS-выражение в атрибуте), то:

Вообще я имел в виду скорее ошибки работы с БД, например. И что значит "На объекте пространства имен шаблонизатора генерируется ошибка:"? Ошибку надо прямо в шаблоне обрабатывать? Опять же слишком много кода в шаблонах, на мой взгляд.

Всё-таки есть некий предел. В PHP его нет.

Так дело же не в пределе. Php, несмотря на отсутствие предела, удобен как шаблонизатор. В нем код записывается в виде кода, а не в виде разметки.

Думать надо не кодом, а конструкциями. Тогда не будет возникать таких мыслей.

Это как? O.o

Продолжай

1. Не хватает or. Пример and:
   

   {{#cond1}}{{#cond2}}test{{/cond2}}{{/cond1}}
   

2. Не хватает встраивания кода в шаблон, в отдельных случаях, я таких два пока что обнаружил:
   
   
   • Автоматическое добавление времени изменения файла к url, что-то типа
     

     <link rel="stylesheet" href="{{#add_timestamp}}/css/index.css{{/add_timestamp}}">
     

   • Перевод фраз с подстановкой данных, что-то типа
     

     {{@:пользователь (?(м)отпавил)(?(ж)отпавила) Вам сообщение.}}
     

     
     И сюда надо как-то передать пользователя, м и ж.

В общем-то я эти проблемы как-то решил, но это заставило меня задуматься о слишком минималистичном синтаксисе.

Да. Если будет решено убирать блок online-пользователей, его придется убирать и в шаблоне и в логике. В шаблоне найти легко, в логике сложнее, смотря какой там код.

Представь обычную рабочую ситуацию: пришел таск убрать некий блок. У нас сейчас достаточно скинуть задачу на верстака и он всё сделает. А так придется напрягать как верстака так и кодера. Круто? Я считаю что нет.

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

Кроме того, следующий момент остался без примера:

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