В чем преимущество шаблона без логики (например, усов)?

101

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

Однако нет объяснения, почему он разработан без логики. Другими словами, в чем преимущество шаблона без логики?

Морган Ченг
источник

Ответы:

107

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

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

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

Мигель Пинг
источник
30
Итак, почему это хорошо, что код контроллера ДОЛЖЕН обрабатывать данные именно в той форме, которая необходима для представления данных определенным образом? Почему это хорошо, что изменение представления часто требует изменения кода контроллера? Мне это кажется плохим. Я думал, что одна из целей языка шаблонов - отделить логику контроллера от логики представления. Глупый шаблон, который не может принимать никаких решений, заставляет логику представления возвращаться в код контроллера. В организациях, где над презентацией работает другой человек, они не могут делать свою работу самостоятельно.
jfriend00
8
Вы не должны подготавливать данные для представления в вашем контроллере. Контроллер предназначен для управления потоком приложений. Вместо этого вам следует создать класс презентатора, который преобразовывает вашу модель в модель представления, которая затем используется представлением. Модель представления - это модель пользовательского интерфейса, которая отделена от модели, которая является частью бизнес-логики. Я рекомендую вам посмотреть лекцию
ragol
1
Он вводит некоторую логику представления в контроллер, но это помогает смешивать различные уровни представления. Если вы хотите, чтобы аналогичные данные были представлены в формате JSON, HTML или XML, не следует искажать данные на 100% в шаблоне HTML. Это оставит JSON и XML для собственной логики отображения скручивания. Вы централизуете 80% логики отображения в контроллере, а остальные 20% встраиваете в лямбды и фильтры.
chugadie
65

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

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

Например, рассмотрим следующий фрагмент шаблона с использованием усов :

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Я могу это понять, но считаю следующее (с использованием подчеркивания ) более простым и понятным :

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

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

Брэд
источник
135
Я удивлен, что вы чувствуете, что шаблон подчеркивания проще ... мне он кажется намного менее читаемым. Просто мнение :-)
Бен Клейтон
9
@ Ben-Clayton Я согласен с тем, что первый синтаксис красивее и, возможно, более читабелен. Однако я говорю о сложности, когда говорю «просто».
Брэд
1
Иногда использование тернарного оператора уместно в шаблоне независимо от того, какая у вас логика. Или что, если я хочу вывести количество элементов в массиве? Не знаю, как использовать усы, вроде этого не хватает.
Пол Шапиро
5
@PaulShapiro Вы должны сгенерировать количество элементов в массиве вне шаблона и сохранить его в отдельной переменной.
Сеун Осева
4
@brad, шаблон подчеркивания представил дыру XSS: nameи itemsмог содержать JavaScript.
Мэтью
28

Усы лишены логики?

Разве это не так:

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

Довольно похоже на это?

if x
  "foo"
else
  "bar"
end

И разве это не похоже на логику представления (читай: почти на определение)?

pje
источник
17
Да, если вы просто оцениваете истинность объекта, но попытаться сделать что-то более сложное невозможно ( if x > 0 && x < 10) ... Итак, хотя можно использовать Mustache с логикой или без нее, решать вам. В конце концов, это всего лишь инструмент.
Том Эшворт,
5
Вы неправильно смотрите на это. Тот факт, что вы можете делать на языке несколько вещей, которые не соответствуют его общей парадигме, не означает, что язык не соответствует этой парадигме. Вы можете писать императивный код на Java или Haskell, но при этом нельзя сказать, что это делает Java не объектно-ориентированным языком, а Haskell - функциональным языком. Посмотрите, что язык позволяет вам легко делать и к чему он ведет, чтобы понять, что это за язык.
cjs
@ CurtJ.Samps: ваша аналогия имела бы смысл, если бы Java продавалась как «безфункциональная» или если бы Haskell продавался как «безобъектно-ориентированный». Этот ответ демонстрирует, что выражение «без логики» в лучшем случае неверно.
Кори
1
Думаю, вы согласны со мной в том, что когда мы называем язык «функциональным», мы имеем в виду «стремление к функциональному». Разногласие, похоже, состоит в том, что я определяю «без X» как «стремление от X», тогда как вы определяете его как «полностью неспособный к X».
cjs
13

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

Из руководства по усам :

Мы называем это «без логики», потому что здесь нет операторов if, предложений else или циклов for. Вместо этого есть только теги. Некоторые теги заменяются значением, некоторые - ничем, а другие - серией значений. В этом документе объясняются различные типы тегов усов.

Джереми
источник
6
Описание немного сложное, поскольку разделы работают как условные выражения и циклы, только очень ограниченные. Возможность ссылаться на вызываемые объекты в хэше также позволяет преобразовывать разделы в элементарный язык программирования. Тем не менее, по крайней мере, это затрудняет идти по этому пути, а не поощряет его.
Том Андерсон
1
Конечно, но система шаблонов без блоков для условий и итераций была бы относительно бесполезной. В самом шаблоне не указано, для чего предназначен блок или как он обрабатывается.
Джереми
12

Обратной стороной медали является то, что в отчаянной попытке убрать бизнес-логику из презентации вы в конечном итоге добавляете в модель много логики презентации. Типичным примером может быть то, что вы хотите поместить «нечетные» и «четные» классы в чередующиеся строки в таблице, что можно сделать с помощью простого оператора по модулю в шаблоне представления. Но если ваш шаблон представления не позволяет вам это сделать, тогда в данных вашей модели вы должны не только сохранить, какая строка является нечетной или четной, но в зависимости от того, насколько ограничен ваш механизм шаблонов, вам может даже потребоваться загрязнить вашу модель. с именами реальных классов CSS. Представления должны быть отделены от моделей, точка. Но модели также должны быть независимыми от представлений, и именно об этом заставляют забыть многие из этих «не логических» шаблонизаторов. Логика идет в обоих местах,собственно, чтобы правильно решить, куда он идет. Это проблема презентации или проблема бизнеса / данных? Чтобы иметь 100% первозданный вид, загрязнение попадает в другое менее заметное, но столь же неподходящее место.

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

mattmc3
источник
6
Должен с тобой не согласиться. Логика представления для шаблонов без логики входит не в модель, а в представление, которому она принадлежит. Представление принимает необработанные данные модели и при необходимости обрабатывает их (путем аннотирования нечетных / четных строк и т. Д.), Чтобы подготовить их к презентации.
acjay
1
Почему представления не могут быть чем-то большим, чем шаблоны, и включать код для обработки данных для шаблона?
LeeGee
1
acjohnson55 - Я согласен с вами насчет того, куда он должен идти (просмотр), но шаблоны без логики многое из этого не допускают. @LeeGee - Я думаю, что есть обратная реакция на слишком много логики в представлениях, но все зашло слишком далеко в другом направлении, чтобы предотвратить даже логику, специфичную для представления в представлениях.
mattmc3
4
Я знаю, что опаздываю на вечеринку, но для чередования цветов строк следует использовать CSS nth-item (odd).
DanRedux
1
Нет ничего плохого в том, что промежуточный объект представления создается представлением из моделей и коллекций или любых других данных. Таким образом, представления создают данные представления, которые объединяются с шаблоном для визуализации представления.
wprl
11

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

болван
источник
2
Вы можете объяснить это более подробно?
Морган Ченг,
29
Потратьте три месяца на работу над системой с использованием логического языка шаблонов, такого как JSP, с программистами, которые не рьяно разделяют логику и представление. Вы обнаружите, что создаете систему, в которой, по сути, есть программирование на странице - арифметика для макета таблицы, условия для отображения информации о ценах и т. Д. Языки шаблонов - чрезвычайно плохие языки программирования, поэтому это становится кошмаром для разработки и обслуживания. Что-то вроде «Усы» вообще не позволяет попасть в такую ​​ситуацию.
Том Андерсон
Если логика представлена ​​в форме функции, она может использоваться системой микрошаблонов, которая поддерживает встроенную логику и модульное тестирование. Наихудшей идеей мне кажется «помощники» руля (см. Spin.atomicobject.com/2011/07/14/… «Расширенное использование») - их невозможно протестировать, поскольку они находятся внутри скрипта / теги type / text вместо тегов простого старого сценария (/ type / javascript)
Dexygen
8

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

Далее следует мини-разглагольствование (не обращайте внимания):

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

Теперь моя напыщенная речь идет полным ходом: :-)

Я думаю, если довести многие идеи до крайности, результат станет смехотворным. И иногда (то есть в этой теме) проблема заключается в том, что мы доводим «неправильную» идею до крайности.

Убирать всю логику из представления - «нелепо» и неправильная идея.

Отступите на мгновение.

Нам нужно задать себе вопрос: зачем убирать логику? Концепция, очевидно, заключается в разделении интересов . Держите обработку представления как можно более отдельной от бизнес-логики. Зачем это делать? Это позволяет нам поменять местами представления (для разных платформ: мобильные, браузерные, настольные и т. Д.), И это позволяет нам более легко поменять местами поток управления, последовательность страниц, изменения проверки, изменения модели, доступ безопасности и т. Д. Также, когда логика удаленный из представлений (особенно веб-представлений), он делает представления более читаемыми и, следовательно, более удобными в обслуживании. Я понимаю и согласен с этим.

Однако первоочередное внимание следует уделять разделению интересов. Не представления, на 100% лишенные логики. Логика внутри представлений должна относиться к тому, как визуализировать «модель». Насколько я понимаю, логика представлений в порядке. У вас может быть логика представления, которая не является бизнес-логикой.

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

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

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

В одном проекте, в котором я принимал участие, мы пытались довести идею бессмысленного взгляда до смехотворной крайности. У нас был собственный шаблонизатор, который позволял нам отображать объекты модели в html. Это была простая система на основе токенов. Это было ужасно по одной очень простой причине. Иногда в представлении нам приходилось решать, следует ли мне отображать этот небольшой фрагмент HTML ... или нет ... Решение обычно основывается на некотором значении в модели. Когда у вас нет абсолютно никакой логики в представлении, как вы это делаете? Вы не можете. У меня были серьезные споры с нашим архитектором по этому поводу. Люди, занимающиеся интерфейсом HTML, пишущие наши представления, были полностью расстроены, когда столкнулись с этим, и были очень напряжены, потому что не могли достичь своих простых целей. Поэтому я представил концепцию простого IF-оператора в нашем движке шаблонов. Я не могу описать вам наступившее облегчение и спокойствие. Проблема была решена с помощью простой концепции IF-Statement в наших шаблонах! Внезапно наш шаблонизатор стал хорошим.

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

Я понимаю, что когда вы заявляете, что «у вас не должно быть логики в представлениях», становится легко узнать, когда вы являетесь «хорошим» программистом. (Если это ваша мера доброты). Теперь попробуйте реализовать веб-приложение даже средней сложности с указанным выше правилом. Это не так-то просто сделать.

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

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

Я закончил свою тираду. :-)

Привет,

Дэвид

Дэвид Бальм
источник
отличный ответ, все дело в хороших методах программирования ... и, кстати, повторное использование шаблонов без логики на сервере и клиенте - это не СУХОЙ, потому что вам придется дублировать логику в обоих ...
mateusmaso
5

Лучший аргумент, который я придумал для шаблонов без логики, - это то, что вы можете использовать одни и те же шаблоны как на клиенте, так и на сервере. Однако на самом деле вам не нужен бессмысленный, просто тот, у которого есть свой «язык». Я согласен с людьми, которые жалуются, что усы бессмысленно ограничивают. Спасибо, но я большой мальчик и могу содержать свои шаблоны в чистоте без вашей помощи.

Другой вариант - просто найти синтаксис шаблонов, который использует язык, поддерживаемый как клиентом, так и сервером, а именно javascript на сервере, либо с помощью node.js, либо вы можете использовать интерпретатор js и json через что-то вроде therubyracer.

Затем вы можете использовать что-то вроде haml.js, которое намного чище, чем любой из приведенных до сих пор примеров, и отлично работает.

Eagspoo
источник
Я полностью согласен. После некоторого чтения я пришел к выводу, что возможность создания шаблонов на JS как на стороне клиента, так и на стороне сервера удовлетворяет мои потребности лучше, чем набор конкретных языков шаблонов
Christofr
4

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

Ядро Джеймса
источник
3

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

Цель шаблона - отрисовать что-то, а не выполнять бизнес-логику. Теперь есть тонкая грань между невозможностью делать то, что вам нужно сделать в шаблоне, и наличием в них «бизнес-логики». Несмотря на то, что я был очень позитивно настроен по отношению к Moustache и пытался использовать его, в конце концов я не мог делать то, что мне нужно, в довольно простых случаях.

«Массование» данных (если использовать слова в принятом ответе) может стать настоящей проблемой - не поддерживаются даже простые пути (то, что адресовано Handlebars.js). Если у меня есть данные просмотра, и мне нужно настраивать их каждый раз, когда я хочу что-то отрендерить, потому что мой шаблонизатор слишком ограничивает, тогда это в конечном итоге не поможет. И это побеждает часть платформенной независимости, которую усы заявляют сами; Я должен везде дублировать логику массажа.

Тем не менее, после некоторого разочарования и после опробования других шаблонизаторов мы закончили тем, что создали наш собственный (... еще один ...), который использует синтаксис, вдохновленный шаблонами .NET Razor. Он анализируется и компилируется на сервере и генерирует простую автономную JS-функцию (фактически как модуль RequireJS), которую можно вызвать для «выполнения» шаблона, возвращая в качестве результата строку. Образец, приведенный Брэдом, будет выглядеть следующим образом при использовании нашего движка (который я лично считаю намного лучше, чем Mustache и Underscore):

@name:
<ul>
@for (items) {
  <li>@.</li>
}
</ul>

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

Мы решили это, реализовав язык запросов, вдохновленный XPath, который мы назвали JPath. По сути, вместо использования / для перехода к дочерним элементам мы используем точки, и поддерживаются не только строковые, числовые и логические литералы, но также объекты и массивы (как JSON). Язык не имеет побочных эффектов (что является обязательным условием для создания шаблонов), но позволяет «массировать» данные по мере необходимости путем создания новых буквальных объектов.

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

Шаблон таблицы:

<table>
    <thead>
        <tr>
            @for (columns) {
                <th>@title</th>
            }
            @if (actions) {
                <th>Actions</th>
            }
        </tr>
    </thead>
    <tbody>
        @for (rows) {
            @partial Row({ row: ., actions: $.actions, columns: $.columns })
        }
    </tbody>
</table>

Шаблон строки:

<tr id="@(row.id)">
    @for (var $col in columns) {
        <td>@row.*[name()=$col.property]</td>
    }
    @if (actions) {     
        <td>
        @for (actions) {
            <button class="btn @(id)" value="@(id)">@(name)...</button>
        }
        </td>
    }
</tr>

Вызов из JS-кода:

var html = table({
    columns: [
        { title: "Username", property: "username" },
        { title: "E-Mail", property: "email" }
    ],
    actions: [
        { id: "delete", name: "Delete" }
    ],
    rows: GetAjaxRows()
})

В нем нет бизнес-логики, но он может быть повторно использован и настроен, а также не имеет побочных эффектов.

Lucero
источник
13
Честно говоря, я не вижу смысла в этом ответе, он вообще не отвечает на вопрос. Вы говорите, что есть ограничения, но не описываете, что это такое и как они возникают. Наконец, вы начинаете обсуждение своей собственной системы, которая недоступна никому другому, на самом деле она может быть отстойной и может однажды оказаться на thedailywtf, но мы никогда не узнаем. Откройте исходный код, дайте ссылку на него и давайте решать!
mattmanser
1
@mattmanser, я действительно пишу об ограничениях, которые привели к неиспользованию Mustache (и Handlebars): отсутствует поддержка путей, предикатов, переменных, преобразования данных для вызова частичных файлов. Все это было важно для нас. Мы, вероятно, когда-нибудь откроем исходный код кода, но поскольку это решение на стороне сервера (или время компиляции, если хотите), которое компилирует шаблоны в код JS, у него не будет такой большой аудитории, как у Mustache. Если вы хотите войти в контакт, не стесняйтесь обращаться ко мне - я также являюсь автором bsn GoldParser в коде Google (где вы можете легко найти мою электронную почту в файле readme).
Lucero
Мне нравится идея твоего бритвенного движка ... это открытый исходный код?
Cracker
@Cracker, нет (пока) - проблема в том, что в настоящее время шаблоны скомпилированы в JS-код на сервере, на котором запущен ASP.NET MVC, и поэтому целевая аудитория не такая большая, как у других движков шаблонов. . В дополнение к этому, это часть более крупной библиотеки, которую мы сначала должны разобрать, чтобы открыть ее исходный код.
Lucero
1
@Esailija Позволяет динамически указывать имена свойств, которые будут взяты из rowобъекта, вместо использования статических имен. Например, если $col.property == 'Something'тогда это приведет к содержимому row.Something.
Lucero
2

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

CoffeeScript (с Reactive Coffee Builder DSL) - 37 символов

"#{name}"
ul items.map (i) ->
  li i

Нокаут - 100 символов

<span data-bind="value: name"/>
<ul data-bind="foreach: items">
   <li data-bind="value: i"/>
</ul>

Руль / усы - 66 символов

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Подчеркивание - 87 символов

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

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

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

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

Дин Рэдклифф
источник
@brad, что ты думаешь об этом сравнении?
Дин Рэдклифф
2

Основные преимущества использования шаблонов без логики:

  • Строго обеспечивает разделение модели и вида , подробности см. В этом документе (настоятельно рекомендуется)
  • Очень легко понять и использовать , потому что не требуется логики программирования (и знаний!), А синтаксис минимален.
  • (в частности, Moustache) очень портативен и не зависит от языка, может использоваться без изменений практически во всех средах программирования
Рмюллер
источник
отличный лаконичный ответ!
MrWatson
1

Я согласен с Брэдом: underscoreстиль легче понять. Но я должен признать, что синтаксический сахар может понравиться не всем. Если _.eachэто несколько сбивает с толку, вы можете использовать традиционный forцикл.

  <% for(var i = 0; i < items.length; i++) { %>
    <%= items[i] %>
  <% } %>

Всегда хорошо, если вы можете вернуться к стандартным конструкциям, таким как forили if. Просто используйте <% if() %>или в <% for() %>то время как Mustacheиспользуйте неологизм для if-then-else(и сбивает с толку, если вы не читали документацию):

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

Движок шаблонов хорош, когда вы можете легко создавать вложенные шаблоны ( underscoreстиль):

<script id="items-tmpl" type="text/template">
    <ul>
        <% for(var i = 0; i < obj.items.length; i++) { %>
            <%= innerTmpl(obj.items[i]) %>
        <% } %>
    </ul>
</script>

<script id="item-tmpl" type="text/template">
    <li>
        <%= name %>
    </li>
</script>

var tmplFn = function(outerTmpl, innerTmpl) {
    return function(obj) {
        return outerTmpl({obj: obj, innerTmpl: innerTmpl});
    };
};

var tmpl = tmplFn($('#items-tmpl').html(), $('#item-tmpl').html());
var context = { items: [{name:'A',{name:'B'}}] };
tmpl(context);

В основном вы передаете свой внутренний tmpl как свойство вашего контекста. И назовите это соответственно. Сладкий :)

Кстати, если единственное, что вас интересует, это механизм шаблонов, используйте автономную реализацию шаблона. При минификации это всего 900 символов (4 длинные строки):

https://gist.github.com/marlun78/2701678

Роланд
источник