Не знаю, не пользовался. Хотя тестировать отдельные методы - как раз легко.

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

{
  message: 'ReferenceError: data is not defined',
  templatePath: 'путь к шаблону',
  TypeError: 'RenderError',
  nodeName: 'имя тега',
  line: 'номер строки',
  char: 'позиция символа, с которого начинается тег'
}

2. Тег со всем содержимым не попадает в результат.
3. Если использовать опцию конфига debug - true, на месте тега будет сгенерирован html-код:

<h3>RenderError:<br /> ReferenceError: data is not defined<br />Template: templates\page.xml<br />Node name: if<br />Line: 30<br />Char: 2</h3>

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

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

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

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

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

Это как? O.o

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

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

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

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

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

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

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

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

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

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

Да, замудрил. В общем, вот как это отлавливается:

TEN.on('error', function () {});

Какие сайчас могут быть ошибки на этапе шаблонизации:

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

2. Ошибки получения данных. Типо:
Могут возникать как в пассивных, так и в активных шаблонах. Не передали тебе объект в нужном ключе - обрабатываем на уровне разметки. Нет соединения с базой - вернули объект ошибки - обработали на уровне разметки.
Эти ошибки так же могут быть обработаны на уровне логики получения этих данных.


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

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

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

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

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


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

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

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

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

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

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

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

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

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

"только в 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}}

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

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

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

Это не ошибки парсинга (компиляции). Это ошибки выполнения кода (синтаксические, эксепшны и т.п.).

Метод может выкинуть исключение.

Приведи пример. Желательно с учетом того, что ручки асинхронны.

Согласен, это можно легко организовать.

Нет кода. Есть только конструкции и выражения внутри конструкций.

Это твоё личное мнение :)

Где тут аргументы, параметры? Никакой реюзабельности, гибкости. Отдельный метод на конкретное действие. Если понадобится выводить 10 пользователей в одном месте, а 20 в другом - придется писать 2 метода. Так что пример не засчитан, c таким же успехом я могу написать так:

<ten:context object="online_users()">
</ten:context>

В соседней теме люди писали что в основном всё понятно с первого взгляда, без доки. Может ты просто не понял самого принципа? Скажи какое конкретно место не понятно.
Чем? Так работает весь маркет, все проекты на xscript-те. Только там активная и пассивная части разделены по файлам, у меня же всё вместе.

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

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

<call function="f">
    <arg value="1">
    <arg value="2">
    <arg value="3">
</call>

:)

ты суслика видишь? Конструкции - это только оправдание. Типа это не код, это конструкции. Которые на самом деле код, императивный код.

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

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

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

Они разделены, смотри пример выше.
Я не знаю уже как объяснять. Мы, походу, о разных вещах говорим.
Вызвал функцию с аргументом - числом. Функция ожидала строку. Либо функция сама падает (например, пытается применить к аргументу метод строки), либо она проверяет тип и выкидывает исключение. Т.е. это то же самое, что и ошибка программиста, о которой ты писал выше.

Что касается ошибок обращения к ресурсам. Сами обращения происходят в недрах логики метода, вызываемого из шаблона, правильно? В ноде принято в callback первым параметром прокидывать объект ошибки, если это имеет место быть. Так вот, допустим в недрах этого метода возникла ошибка обращения к ресурсу и логика метода это отловила. Метод может передать в callback этот объект и уже в шаблоне на уровне разметки это обработается. Пример:

<ten:query method="getOnline" params="error, data">
  <ten:if expr="error">
    <!-- произошла ошибка доступа к ресурсам или ещё что -->
  <ten:else if="data" />
    <!-- всё ок, пришли данные, обрабатываем их -->
  </ten:if>
</ten:query>

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

Это у меня записывается не так, не стоит надумывать :)
Тем более, в том же Dust можно вызывать функции и обрабатывать от них результат. Логика таких конструкций ничем не отличается от моего шаблонизатора (см. пример с query, context), кроме синтаксиса самих конструкций.

Любой шаблон на самом деле код. Тем более в JS. Почему, когда ты пишешь конструкцию в стиле Mu, ты не относишься к этому как к коду? Или я чего-то не до понял?

А мне не нравится такой подход. Мне страшно представлять огромное дерево данных. Особенно, когда они максимально соответствуют структуре представления. Пока никаких веских аргументов я не увидел (или плохо смотрел?), кроме религиозных убеждений. Из всего нашего диалога мне больше всего интересно узнать по-че-му надо так а не так? Я правда хочу знать, открой мне глаза :)

Ох. Ну где я записываю код разметкой? Вызовы методов? If-ы? Циклы? Кстати циклы (итераторы, ага), ифы, вызовы функций есть в каждом приличном шаблонизаторе. Чем мой от них отличается?
А, я понял. Тебе нравятся шаблоны типа:
Хм. Поэтому не нравится? Т.е. если мне это не надо - то говно. Так получается?

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

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

А, меня просто твои "исключения, выкидываемые методами получения данных (ручка)" сбили с толку.

О, отлично объяснил. Я правда такими вещами не заморачиваюсь

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

О, а как?

есть код с состоянием (императивный) и побочными эффектами, а есть декларативный (функциональный) код.

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

2) моя религия (читабельность, разделение обязанностей) ни чем не хуже твоей (по-меньше дергать кодера);

3) у меня складывается впечатление, что ты все что я говорю (по-крайней мере в последнее время) ты списываешь на религию, это так?

они самые

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

Точнее кодеров спрашивать. Где я сказал говно? Я говорю, что передо мной не стоят твои проблемы и расскащываю, какие проблемы стоят передо мной. Хотя не то чтобы проблемы, скорее свои приоритеты.

Ну если для тебя это проблема, ее надо решать. Я ж не против.

декларативный - в котором если и вызываются функции, то для преобразования, а не получения данных

да, давай приведу пример:

<?xml version="1.0" encoding="UTF-8"?>
<ten:root xmlns:ten="TEN" xmlns="http://www.w3.org/1999/xhtml">
    <ten:block>
    <ten:query method="getOnline" params="error, data">
        <ten:each object="data" item="user">
            <ten:echo data="user.name" />
        </ten:each>
    </ten:query>
    </ten:block>
</ten:root>

и как-нибудь так:

{{#onlineUsers}}
    {{name}}
{{/onlineUsers}}

this.onlineUsers = getOnline();

Ну да, к этому и стремлюсь.

Мне известно это выражение и цель его ясна. Но я стараюсь смотреть на реальные потребности, в отличии от религии.

:lol:

Ну моя заключается не только в этом (читай выше). Я пытаюсь объединить оба суждения.

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

Смысл? Что даст? Православным станешь? (ога, я тролль :))

Своего нет.

Ну ты сказал - тебе не нравится. Если ты не в курсе, для меня твоё мнение авторитетно, но нужны основания. Раз не нравится - значит говно, ну или окологовённое состояние.

Мой шаблонизатор не первый в этом роде и этим пользуются (monolithed, помогай).

Общую суть твоей религии я понял, остается только понять чем она лучше и что она дает как кодеру так и верстаку.

Ну лучше же когда всё в одном месте, рядом. Может тебе просто стоит попробовать?! Я считаю стоит.


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