TrueTemplates - самый быстрый или безопасный шаблонизатор
 

использовать так:

var wrongField= TT.string( 'field "{0}" is not found' )
..
throw wrongField([ 'xxx' ])

var makeUserTagLink= TT.uri( '/user/{user}/tag/{tag}' )
..
location.href= makeUserTagLink({ user: 'tenshi', tag: 'xxx' })

var makeContent= TT.dom( '<h1>{title}</h1><p>{text}</p>' )
..
contentNode.appendChild( makeContent({ ttle: 'xxx', text: 'xxx not found' }) )

скачать: http://bca07c6c88b166729f9741ef748fc...oject/tt/tt.js - 2.5кило

Какой-то API неудобный, почему бы не сделать так:

var wrongField = new TrueTemplate("field “{0}” is not found");
throw wrongField.match(["xxx"])

?

--------
а… там разные типы, ну все равно не очевидно, что string, uri или dom вернут функцию.


--------
Даже если от new избавится:

var wrongField = TrueTemplate("field “{0}” is not found");
throw wrongField.match(["xxx"])

было бы удобнее, чем возвращать фукнцию.

А необходимость автоматического encodeURIComponent и парсинга HTML в функционале шаблонизатора сомнительна.

а что нужно вызвать match - это очевидно? х)

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

var object = new Constructor(…);
object.method(…)

"привычная всем схема" не удобна в использовании

Вчера прочитал статью по этому шаблонизатору. Код пугает немного. Например:

var link= TT.dom( '<a href="{uri}">{title}</a>' )({ uri: '/', title: 'на старт' })

Это же можно сделать проще, выполняя одну функцию вместо двух.

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

:)

По мне так это не шаблонизатор, а навороченый sprintf.

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

Нет такой идеи. Есть идея разделения бизнес-логики и логики отображения. В обоих случаях нужна логика. Просто одна не должна вмешиваться в другую.

проще - не всегда лучше, один - не всегда лучше, чем два ;)

Спасибо, КО, но это не тот случай, имхо.

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

это как, например?

В место текста передать ноду:

var link= TT.dom(dom)({ uri: '/', title: 'на старт' })

где dom что-то вроде этого:

<a href="{uri}">{title}</a>

в фф будет что-то вроде этого:

<a href="http://example.org/sample/path/%23uri%24">{title}</a>

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

Вот к примеру, есть у меня табы. Их можно удалять/добавлять. Для добавления таба необходимо как минимум 2 ноды - вкладку и контейнер для контента.
Можно создавать это динамически, но тогда данные (html) будут внутри логики (js), что не есть кошерно. Хранить эти же данные в виде строки ещё хуже - вдруг будет большой кусок? Правильнее, я считаю, брать эти "шаблоны" из html (либо ещё откуда, но не из js-кода). Как в таком случае использовать шаблонизатор? innerHTML вытаскивать постоянно? Конечно, можно это прикрутить к самому шаблонизатору, но это не самый надежный вариант.

Это просто мысли в слух, так сказать:)

Да везде будет что-то вроде этого.

в таком случае поддержка нод в качестве шаблонов не нужна

не на что..

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

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

если не понял, я имел в виду, что это тот случай

кошерно и правильно требуют обоснования. А в большинстве случаев они означают "по религиозным убеждениям" ;)

p.s. и ты не пропустил это сообщение?

А кто говорил про аякс?

http://ru.wikipedia.org/wiki/MVC
ну и:
В таком случае поддержка синтаксиса html в шаблонах не нужна. JSON куда лучше с этим справится.

ты предлагаешь транспорт шаблонов их хтмл встроить в шаблонизатор. это не его уровня задача.
её и нету
с чем?

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

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

это текст, содержащий угловые скобки

какая связь между json и html?

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

Это у тебя он содержит. И они тут не причем, т.к. мы говорили о поддержке такого представления в виде шаблона. Основная мысль в том, что шаблон может нам вернуть ноду (не важно в каком виде пришел шаблон), а принять её не может.

Я говорил не о технологиях, а о формате шаблона. Если JSON будет форматом шаблона, это, как минимум, сократит его объем. На крайняк можно придумать другой формат шаблона, например те же селекторы. Почему именно html?

Вот это правильно:)

а почему он должен её принимать? х)

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

требует доказательства

Да не должен, успокойся:)
Просто у меня свое видение на счет шаблонизатора, вот и интересуюсь, чо да как.

Заметь, я предлагал существующие варианты синтаксиса.

какое видение?

какой смысл писать шаблоны на языке, отличном от целевого?

В моем представлении, шаблоны данных (html) должны быть в чистом виде (html/xml), т.е. в виде тех же данных, а не строка или ещё чего либо.

Да не уговариваю я тебя, мнением интересуюсь. Почему у тебя так, а не, например, так.

ну, я в принципе согласен ^^ я вообще сторонник xslt
но кроме html есть ещё много применений шаблонам.. те же uri

Ну хоть кто-то со мной согласен:)
Kolyaj, например, любит со мной поспорить:)

это ничего не обосновывает. Есть логика представления и есть бизнес-логика, и шаблон - это не только html, но и логика. На каком она языке (javascript, php, etc) не важно. Ты можешь хранить разметку (html), внешний вид (css) и бизнес-логику (js) в отдельных файлах. Но если разметка динамическая, то в этом же файле будет и логика представления, например, на js. И никак это MVC не противоречит

кстати, для тех кто не в курсе, тут недавно еще один шаблонизатор "пробегал", и B~Vladi на него, похоже, намекал местами

и я, я тоже люблю с тобой поспорить :) особенно, когда ты говоришь "Я считаю, правильно было бы..." ;)

шаблон - это только html. а вот view - это не только шаблон.

Это говорит о том, что не по "религиозным убеждениям", а по известному шаблону проектирования.
Да нет логики представления. "Такой же, но с перламутровыми пуговками" - где логика?
Я считаю, что шаблоном могут быть только данные. Шаблон поведения ты как себе представляешь? И как его можно преобразовывать?
Аха, я в курсе. А у вас своего мнения нет, всё ссылки какие-то даёте.

Не люблю, ты провокатор.

Вот например. Но я демонстративно промолчу. :)

Ты сам этого не замечаешь наверно.
А ты демонстратор:D

и программа - это тоже данные х)