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

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

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

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

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

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

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

усы без логики?

не так:

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

очень похоже на это?

if x
  "foo"
else
  "bar"
end

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

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

с руководство ус:

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

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

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

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

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

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

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

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

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

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

теперь мой разглагольствования продолжаются полным ходом:: -)

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

удаление всей логики из представления является "смехотворным" и неправильной идеей.

отойдите на минутку.

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

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

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

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

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

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

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

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

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

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

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

спасибо,

Дэвид

в одном предложении: Logic-less означает, что сам механизм шаблонов менее сложен и поэтому имеет меньший размер, и есть меньше способов для него вести себя неожиданно.

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

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

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

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

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

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

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

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

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

<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()
})

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

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

в CoffeeScript (с Реактивные Кофе 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 старой школы.

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

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

Я согласен с Брэдом: the 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}}

Template engine отлично подходит, когда вы можете легко создавать вложенные шаблоны (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

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

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