Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
Ну или {{mustache}}.

Здравствуйте, c-smile, Вы писали:

CS>Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
CS>В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
CS>Ну или {{mustache}}.

А чем это лучше чем шаблоны jQuery?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
CS>>В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
CS>>Ну или {{mustache}}.

VD>А чем это лучше чем шаблоны jQuery?

Основные критерии template definition languages:
1) Компактность и "неинтрузивность" синтаксиса. Чем компактнй — тем лучше — легче понимать. Maintenance лучше одним словом.
2) Скорость исполнения.

В принципе оба TDL позволяют делать примерно одно и то же но {{mustache}}/KiTE синтаксис более компактный.
Скорость исполнения в случае {{mustache}}/KiTE теоретически (и практически в случае KiTE) выше.
jQuery.template без использования оператора with() {} не построить — а это один из основных тормозов.

Вот посмотри на тестах: http://jsperf.com/dom-vs-innerhtml-based-templating/100

Resig Micro Templating                  -   129,220
Resig Micro Templating without 'with'   - 1,589,419

Разница — на порядок.

Как собственно и разница между jQuery.template() от Microsoft и моим KiTE (больше — лучше):

KiTE              - 603,649
jQuery Templates  -  54,745

По поводу TDL:

Это вот jQuery.tmpl():

 <ul>
   {{each contacts}}
     <li><b>${$value.firstName}</b> <i>${$value.lastName}</i></li>
   {{/each}}
  </ul>

Это вот {{mustache}}/KiTE:

  <ul>
   {{#contacts}}
     <li><b>{{firstName}}</b> <i>{{lastName}}</i></li>
   {{/contacts}}
 </ul>

как-то последний мне больше нравится. Конструкции вида ${$value.lastName} достаточно сильно "шумят" синтаксически.
Дело вкуса конечно но тем не менее.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:

G>>Замените уж тогда HTML на что-нибудь читабельное. Вроде HAML.

VD>DSL, конечно, можно прикрутить любой, но что-то я не вижу в HAML-е особой читаемости.

HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

Здравствуйте, Аноним, Вы писали:

А>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

Здравствуйте, c-smile, Вы писали:

CS>Основные критерии template definition languages:
CS>1) Компактность и "неинтрузивность" синтаксиса. Чем компактнй — тем лучше — легче понимать. Maintenance лучше одним словом.

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

CS>2) Скорость исполнения.

А вот скорость, конечно, важна.

CS>В принципе оба TDL позволяют делать примерно одно и то же но {{mustache}}/KiTE синтаксис более компактный.
CS>Скорость исполнения в случае {{mustache}}/KiTE теоретически (и практически в случае KiTE) выше.
CS>jQuery.template без использования оператора with() {} не построить — а это один из основных тормозов.

CS>Вот посмотри на тестах: http://jsperf.com/dom-vs-innerhtml-based-templating/100
CS>

CS>Resig Micro Templating                  -   129,220
CS>Resig Micro Templating without 'with'   - 1,589,419
CS>

CS>Разница — на порядок.

А кто такой "Resig Micro-Templating with += instead of push and join" и что это за 'with'?

CS>Как собственно и разница между jQuery.template() от Microsoft и моим KiTE (больше — лучше):
CS>

CS>KiTE              - 603,649
CS>jQuery Templates  -  54,745
CS>

Мне может подойти самый невзрачный и сложный в оформлении шаблонизатор, но шустрый. По большому счету можно даже голый жабоскрипт генерировать. Лишь бы было шустро и надежно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

VD>Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

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

Генерация HTML из HAML прямолинейна, и имена тегов совпадают, так что проблем тут никаких нет.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

VD>Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

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

Здравствуйте, VladD2, Вы писали:

VD>Мне может подойти самый невзрачный и сложный в оформлении шаблонизатор, но шустрый. По большому счету можно даже голый жабоскрипт генерировать. Лишь бы было шустро и надежно.

А собственно в чем проблема-то тогда? Генерируй js функцию. Или отдавай на клиент сгенеренный текст.

Я вообще так и не понял что ты делаешь.

Можешь внятно объяснить зачем тебе вообще шаблоны нужны на client side?
В Nemerle (server side) я еще могу понять. Но как ты это все связать хочешь с client side не ясно.

Здравствуйте, Gaperton, Вы писали:

G>А ты, Влад, совсем не изменился.

Да, ты, как я погляжу — тоже. Все обсуждаешь личности вместо их мыслей .

G>Вместо того, чтобы подумать, начинаешь спорить.

Тут не о чем думать. Аргумент о закрытии тегов надуман. Парсер отлично выявляет это дело.
Заявление о читаемости не более чем высказывание своих вкусов.
А вот зачем людям учить еще один язык ты как-то объяснить забыл.

Что до закрытия тегов, то в нашем случае их можно закрывать без указания имени — </>, как в VB.NET. Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

Здравствуйте, c-smile, Вы писали:

CS>А собственно в чем проблема-то тогда? Генерируй js функцию. Или отдавай на клиент сгенеренный текст.

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

CS>Я вообще так и не понял что ты делаешь.

CS>Можешь внятно объяснить зачем тебе вообще шаблоны нужны на client side?
CS>В Nemerle (server side) я еще могу понять. Но как ты это все связать хочешь с client side не ясно.

Я делаю прототип реактивного фрэймворка поддерживающего иделогию MVVM. Вот первые примеры применения:
HelloWorld.nClickCounter.n
BetterList.n
ControlTypes.n

Общая идея такая. ViewModel и View описывается на сильно усеченном Nemerle. Например, вот как выглядит код ViewModel для редактируемого списка:

	Скрытый текст
	[Record, ViewModel] public class BetterListViewModel { public ItemToAdd : string { get; set; } public AllItems : VMArray[string] { get; set; } public SelectedItems : VMArray[string] { get; set; } public AddItem() : void { when (ItemToAdd != "" && AllItems.IndexOf(ItemToAdd) < 0) // Prevent blanks and duplicates AllItems.Add(ItemToAdd); ItemToAdd = ""; // Clear the text box } public RemoveSelected() : void { AllItems.RemoveAll(SelectedItems); SelectedItems = VMArray.Empty; // Clear selection } } public partial module Views { [View()] public BetterListView(viewModel : BetterListViewModel) : XElement { _ = viewModel; xml <# <div class="note" xmlns=""> <form data-bind="submit:AddItem"> Add item: <input type="text" data-bind='value:ItemToAdd, valueUpdate: "afterkeydown"' /> <button type="submit" data-bind="enable: ItemToAdd().length > 0">Add</button> </form> <p>Your values:</p> <select multiple="multiple" height="5" data-bind="options:AllItems, selectedOptions:SelectedItems"> </select> <div> <button data-bind="click: RemoveSelected, enable: SelectedItems().length > 0">Remove</button> <button data-bind="click: function() { AllItems.sort() }, enable: AllItems().length > 1">Sort</button> </div> </div> #> } }

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

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

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

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

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

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

Здравствуйте, VladD2, Вы писали:

VD>Сейчас вот обдумываю как это дело лучше реализовать. Сначала думал генерировать код работающий с DOM-ом, так как на сервере ХТМЛ разбирается до АСТ. Но меня вот отговорили. Сказали что это медленно. Теперь думаю как лучше формировать код клиентского шаблона. Тупо генерировать конкатенацию строк, или генерировать код на одном из шаблонных движков.

Что-то мне гворит что "Тупо генерировать конкатенацию строк" будет мудро. Зачем тебе а) лишние зависимости и б) ограничения TE?

Здравствуйте, c-smile, Вы писали:

VD>>Сейчас вот обдумываю как это дело лучше реализовать. Сначала думал генерировать код работающий с DOM-ом, так как на сервере ХТМЛ разбирается до АСТ. Но меня вот отговорили. Сказали что это медленно. Теперь думаю как лучше формировать код клиентского шаблона. Тупо генерировать конкатенацию строк, или генерировать код на одном из шаблонных движков.

CS>Что-то мне гворит что "Тупо генерировать конкатенацию строк" будет мудро. Зачем тебе а) лишние зависимости и б) ограничения TE?

Чтобы писать меньше. Я же не коммерческий проект создаю.

В прочем, я уж и сам склонился к генерации конкатенации строк.

Здравствуйте, VladD2, Вы писали:
мыслей .

G>>Вместо того, чтобы подумать, начинаешь спорить.

VD>Тут не о чем думать. Аргумент о закрытии тегов надуман. Парсер отлично выявляет это дело.

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

VD>Заявление о читаемости не более чем высказывание своих вкусов.

Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

VD>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

VD> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

Охрененски важный юзкейс для разработки своих сайтов .

Здравствуйте, Gaperton, Вы писали:

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

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

Что до отбивки, то он пол любому нужна.

G>Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.

VD>>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

G>Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

Там есть чего учить. И потом еще придется постоянно транслировать ХТМЛ в ХАМЛ, так как народ прежде чем заложить что-то в шаблон сначала это что-то создает в коком-нить визивидж-редкаторе.

VD>> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

G>Охрененски важный юзкейс для разработки своих сайтов .

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

В общем, ты уж извини, но неубедительны твои речи.

Здравствуйте, VladD2, Вы писали:

VD>В общем, ты уж извини, но неубедительны твои речи.
У вас тут спор, мне нравятся апельсины, нет яблоки лучше. Если люди которые сознательно отказываются от html в пользу haml, очевидно для них он удобнее. Оптимально делать так, что бы не было жесткой завязки на xml литеры, и если кому то очень хочется haml, мог бы сделать его поддрежку с минимальными усилиями.

Здравствуйте, dotneter, Вы писали:

D>У вас тут спор, мне нравятся апельсины, нет яблоки лучше.

Я и сказал, что речь идет о вкусах.

D>Если люди которые сознательно отказываются от html в пользу haml, очевидно для них он удобнее.

Очевидно. Как очевидно и то, что этим людям не стоит навязывать свое мнение тем, кто с ними не согласен.

Здравствуйте, VladD2, Вы писали:

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

VD>Надуман, надуман.

Не надуман, не надуман.

VD>Если бы это было не так, то все давно бы отказались от использования Си-подобного скобочного синтаксиса.

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

VD>Что до отбивки, то он пол любому нужна.

Если она "по любому" присутствует, то закрывающий тег "по любому" избыточен.

G>>Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

VD>А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.

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

В современных веб страницах, где доминируют теги div, а основную смысловую нагрузку несут их свойства — class и id, мусором является не только закрывающие теги и не нужные угловые скобки, но и сам "div".

То есть, вот этот текст заполнен мусором чуть меньше, чем полностью:

<div class="comment" id="1">
  <div class="head">
  </div>
  <div class="body">
  </div>
</div>

А вот этот, эквивалентный ему — нет:

.comment#1
  .head
  .body

Разница не понятна? Тебе требуются еще какие-нибудь "объективные показатели"?

VD>>>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

G>>Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

VD>Там есть чего учить.

Неужели? И чего же такого там надо учить-непереучить?

VD>>> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

G>>Охрененски важный юзкейс для разработки своих сайтов .

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

Удобнее — пиши с тегами и скобками.

Здравствуйте, Gaperton, Вы писали:

G>Так и происходит. Во многих современных языках применяется двумерный синтаксис. И в тех языках, где он есть, никто не использует скобочный.

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

VD>>Что до отбивки, то он пол любому нужна.
G>Если она "по любому" присутствует, то закрывающий тег "по любому" избыточен.

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

VD>>А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.
G>Есть. Наличие мусора в тексте, не несущего полезной информации, затрудняет читабельность.

Пользуйся брэнфаком или J/K там удельный вес "полезной" информации выше крыши.
Но не в этой теме. Она другому посвящена. А вопрос применения разных ивзращений вроде ХАМЛов меня ни разу не интересует. Если бы интересовал, то я бы так тему и назвал.

G>То есть, вот этот текст заполнен мусором чуть меньше, чем полностью:
G>

G><div class="comment" id="1">
G>  <div class="head">
G>  </div>
G>  <div class="body">
G>  </div>
G></div>
G>

G>А вот этот, эквивалентный ему — нет:

G>

G>.comment#1
G>  .head
G>  .body
G>

G>Разница не понятна? Тебе требуются еще какие-нибудь "объективные показатели"?

Да, понятна. Сверху ХТМЛ, а снизу какой-то суржик который нужно изучить чтобы потом из него все равно получать тот же ХТМЛ. Мне еще один язык не нужен.

Рассуждать о читаемости ХТМЛ-я мне тоже не интересно. Результат нужно получить в нем, и не фига вводить какие-то промежуточные структуры. В правльно написанном коде ХТМЛ-я на одну вьюху должно быть минимальное количество. Соответственно разговаривать просто не о чем.

VD>>Там есть чего учить.

G>Неужели? И чего же такого там надо учить-непереучить?

Еще один язык, твой КО.

VD>>Да уж удобнее чем трансляция в другой язык.
G>Удобнее — пиши с тегами и скобками.

Нивапрос.

Здравствуйте, Gaperton, Вы писали:

G>Не надуман, не надуман...

Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

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