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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

Разве это не:

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

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

if x
  "foo"
else
  "bar"
end

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

Answer 4

Без логического шаблона - это шаблон, который содержит отверстия для заполнения, а не способ их заполнения.Логика размещена в другом месте и сопоставлена ​​непосредственно с шаблоном.Такое разделение интересов является идеальным, потому что тогда шаблон можно легко построить с другой логикой или даже с другим языком программирования.1007 * Мы называем это «без логики», потому что нет операторов if, else, или for for.Вместо этого есть только теги.Некоторые теги заменяются значением, некоторые - ничем, а другие - набором значений.В этом документе объясняются различные типы меток усов.

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

Теперь моя напыщенная речь продолжается в полном разгаре:: -)

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

Удаление всей логики из представления - это «смешно» и неправильная идея.

Отойдите на мгновение.

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

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

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

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

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

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

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

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

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

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

Я закончил с моей напыщенной речью. : -)

Приветствия

David

Answer 8

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

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

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

Answer 9

В одном предложении: «Без логики» означает, что сам механизм шаблонов менее сложен и, следовательно, имеет меньшую площадь и меньше возможностей для непредвиденного поведения.

Answer 10

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

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

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

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

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

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

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

Допустим, мы хотим визуализировать таблицу «сетки данных» с помощью cusomizableЗаголовки и ссылки на действия над строками, а затем динамически добавлять строки с помощью 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()
})

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