[x-yuri]

Какая-то у тебя странная категоризация ошибок: "К этим ошибкам [парсинга] так же относятся исключения, выкидываемые методами получения данных (ручка)." Какого плана исключения?

И этим он удобен? Странный вывод на мой взгляд. Мне жаль верстальщиков и кодеров, которые работают с этим.

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

Кого кому жалко... не думаю, что это способствует конструктивному обсуждению...

А у php как шаблонизатора не большие недостатки (как для меня): 1) невозможно наследование шаблонов, 2) нереализуема защита от дурака, ну и от ошибок типа "забыл проэкранировать переменную". Знаешь, был какой-то период когда я возлагал слишком большие надежды на них (шаблонизаторы), а потом пришло понимание, что native php ни чем не хуже большинства существующих, а то и лучше. Ну и не только у меня так было. Наверное это был акт массового слабоумия

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

Нет, просто останется неиспользуемый метод. Это не так страшно как затраты на агрегацию ненужных данных.

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

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

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

Ну ок, кодер реализовал вывод online-пользователей, прилепил к данным, которые будут отдаваться необходимому шаблону. Верстак написал шаблон. Потом приходит задача, показывать этот блок только в IE8, при полной луне и конкретном get-запросе. Как это лучше запилить? Прокинуть 3 лишних флага и верстак сам if-ами разрулит или пусть кодер это запилит? Пока ответь, а я потом продолжу сценарий.

"только в IE8" - ничего прокидывать не надо, это прямо в шаблоне должно решаться, по поводу полной луны могут быть варианты, а по поводу url - вариантов нету, должно прокидываться из контроллера.

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

Где тут много кода? Не намного больше чем в пассивном шаблоне.

Ну давай сравним...

<ten:query method="getOnline" arguments="" params="error, data">
   <ten:if expr="data">
     <!-- обработка data -->
   </ten:if>
</ten:query>

{{#online_users}}
{{/online_users}}

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

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

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

Как тебе такой сценарий? Можно работать?

Мне-то точно не нравится, это у верстаков надо спрашивать...