за какими именно проектами?

неочевидно, приведи пример

т.е. твой объединенный объединенный вариант - 3-ий вариант, который в зависимости от шаблона "получает нужные данные из источников и передаёт их одной пачкой в шаблон"? Так это чистый 3-ий вариант, получаемые данные определяются шаблоном в любом случае.

почему нет? Я слышал такой аргумент в пользу nodejs, собственно вот

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

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

вы какую-то свою терминологию (а может и реализацию) придумываете, вас трудно понимать. Самый распространенный вариант - контоллеры и экшены. Экшены - действия, контроллеры - группы действий. И url часто имеет вид: /[controller[/action[/id]]], например /users/delete/1 или /users

подожди, ты сравниваешь веб- и десктопные приложения? B~Vladi тебя не об этом спрашивал. И меня этот вопрос тоже интересует (в чем отличие твоей реализации?), потому что я не вкурил её, реализацию... :(

DjDiablo, я все еще помню, что ты обещал помочь с тестированием разобраться :\

p.s. карма напомнила ситуацию в Зимбабве

Раньше мне попадалось что-то подобное, но сейчас не вспомню конкретно. Сейчас - Яндекс.Маркет, например. Хотя там нельзя сказать, что данные запрашиваются из шаблона, но и не из контроллера или ещё чего-то.

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

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

Ну не совсем. В третьем варианте контроллер обращается к источникам, а в объединенном дергаются ручки.

Реализация получения данных в контроллере будет разрастаться.

Возможно в каких-то частных случаях - да (либа там какая-нибудь), а так нет. То же XSL-преобразование. API везде разное ==> разный код.

Не не, всё на один хост/порт уходит с клиента. А статика да, на разные. Но она отдается nginx-ом, так что в контексте разговора нам не интересна.

Ну наверно, не до конца понял это определение. Предлагаешь делать по аналогии с express?

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



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

Кстати, да, даешь инфляцию в интернетах! :D

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

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

какие проблемы я вижу?

1) говрят, в процессе рендеринга шаблона, может выясниться, что другой блок надо перерендерить. Мне никаких конкретных примеров в голову не приходит.

Разве что несколько другой вариант, когда блок может потребовать подключить далее по тексту страницы нужные js-файлы или вставить нужный js-код (вариант, когда теги скрипт указаны перед </body>). Но это вроде решаемо.

Т.е. если обобщить: рендеринг блоков может влиять друг на друга, и должна быть возможность это как-то решать

2) как будут исключения/ошибки обрабатываться?

больше ничего не приходит в голову...

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

ну и не надо забывать, что есть POST (действие) и GET (вывод), т.е. не на каждый запрос надо рендерить шаблон.

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

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

вот и я о том же. Произошла ошибка при подключении какого-то блока в шаблоне. Как и где обработать эту ошибку?

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

php :)

:D как же я мог забыть об этом шаблонизаторе...

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

Чем?

Ну в любом случае это баг, его надо править. Отловить в контроллере это можно, отдав страницу 500 ну и с записью в лог, отправкой e-mail, sms, что угодно :)
Я считаю надо делать так.

В этом случае при поддержке придется править и код класса и шаблон. Тогда как можно править только шаблон.

слишком много знать будет, шаблон

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

кстати, откуда вообще берутся мысли про какие-то лишние данные в случае с пассивным шаблоном?

и расскажи подробнее, как происходит обработка запроса. А то я вот придумал ситуацию, но не знаю, возможно ли такое при твоем подходе: запускается рендеринг шаблона и когда дело доходит до основного контента выясняется, что 404 Not Found. Т.е. весь этот рендеринг выше был ненужным, чего хотелось бы избежать

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

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

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

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

На каком этапе(ах)?

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

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

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

Решено.

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

как?

можно пример?

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

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

с некоторым перекосом в сторону активности шаблона

да, потому что у тебя наследование недекларативное. Декларативность - проще и надежнее (сложнее сделать ошибку), но менее гибка, если это необходимо...

кстати, есть все-таки две вещи, которых немного не хватает в mustache... :)

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

Если тег валится с ошибкой (например, некорректное 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, помогай).

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

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


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

Аналогично, для меня твои реальные потребности - религия.

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

Ты готов слушать о том, что твоя проблема на самом деле не проблема? Может так оно и есть, но ты очень упорно мне не веришь, поэтому смысла тебя убеждать дальше не вижу :)

Ну да, я неудачно выразился. Я просто имел в виду, что для меня это не проблема. И когда я говорю "не нравится", я подразумеваю, что это не объективно, или что я в данный момент не стремлюсь к объективности.

да, monolithed, помогай, а то скучно уже вдвоём становится...

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

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

А почему вы обсуждаете синтаксис шаблонизатора, а не его фичи или их отстутствие (хотя с этого начали)?

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

Если брать такие шаблонизаторы как {{mustaches}}, TSN, Jade, Yammy и пр., то на мой взгляд основная их проблема в том, что пользователь работает не с XML-кодом, а с "текстом", который потом еще нужно прогонять через валидатор, т.е. привинчивать еще один XML-парсер вместо того чтобы сделать все одним инструментом.

С другой стороны, как сказал B~Vladi, TSN может работать с любым форматом данных, поэтому нет смысла привязываться к XML.
Тогда почему бы не сделать дополнение для шаблонизатора, которое бы проверяло валидность XML-кода?

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

Я имел ввиду, то что шаблонизатор B~Vladi, XML-подобный и приводить в пример {{mustaches}} не совсем корректно, т.к. XML-синтаксис довольно ограничен в минималистичности и сделать что-то проще очень сложно.

PS: Еще меня сильно смущает, тот факт что шаблонизатору слишком многое дозволено:

<tsn:if>
	<tsn:else if="typeof this === 'string'" />
</tsn:if>

Если уж отделять логику от представления, то этой логике (typeof this === 'string') явно в шаблоне не место :)

Периодически возникает такая мысль, но когда я смотрю на свою IDE - передумываю, ибо она сама и есть валидатор.
И ещё вопрос - что валидировать? Исходный код или конечный результат? Исходный валидирует IDE, конечный тот инструмент, которому он отдается (браузер, например).


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

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

Если у тебя есть аргументы - да.

Вот! И я о том же. В xscript-е мне приходится постоянно держать перед глазами 3 окна - XML-файл, XML-выдачу и XSL шаблон. Это адски неудобно. Но это составляет единый механизм, поэтому в tsn первое и третье объединено.

Я хз, вроде никак. Этим он и ущербный, имхо.

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

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

Да классная штука, чо :yes:
monolithed, расскажи нам, что вам это дает? И даёт ли.

Честно говоря, не понял. Если там не xml, зачем там xml-парсер?

согласен, вопрос в том, имеет ли смысл усложнять синтаксис с помощью xml

ну тут два выхода: либо, пытаться с этим как-то бороться, либо не пытаться. На мой взгляд не надо, а кто будет так писать, ССЗБ. Но возможно кому-то надо бороться...

Тег block лишний.
Так как функция getOnline синхронна, нет смысла вызывать её из query.
Шаблон должен выглядеть так:

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

Или так:

<ten:each object="getOnline()" item="user">
    <ten:echo data="user.name" />
</ten:each>

если это проблема, может стоит сменить ide? ;) у меня код, отсносящийся к страничке находится в контроллере, виде, шаблоне, js-файле и css-файле. Было бы грустно, если бы оно все было в одном файле. И как-то столько файлов неудобств не вызывают, обычно. Возможно, что-то из этого можно было бы объединить в один файл, опционально, но точно не в одну кучу (как ты предлагаешь), а последовательно, одно за другим.

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

а чего это getOnline - синхронна?

p.s. сорри, не особо старался сделать оптимальный tsn-шаблон... :(

А причем тут IDE? XML и XSL в разных файлах + в браузере XML-выдача. Переключаться между файлами проблем нет, но это лишнее ненужное телодвижение. В основном переключение идет между браузером и XSL, вот тут уже геморройнее.
Я не предлагал всё, только view (включая view-логику).

Ну так ты сам написал:

this.onlineUsers = getOnline();

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

я с xscript не работал, но по опыту работы с несколькими файлами на страницы могу сказать, что для меня это проблем не создает и объединить в один файл желания не возникает. Бывает наоборот удобно открыть один и тот же файл в двух соседних вкладках. Поэтому я предположил, что дело в ide.

да, я именно об этом

потому что: 1) у меня нету такой проблемы, 2) не уверен, что это распространенная проблема, 2.1) если так, то это ненужное усложнение.