Это могут сделать помощники.
Посмотрите на это: http://kan.so/packages/details/handlebars-helpers
Есть помощник ifequal, позволяющий сравнивать два значения.
Аналогичное решение можно использовать для ваших требований.

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

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

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijas совершенно верно, это действительно был бы помощник;) Или нет, так как if-block настолько элементарен.
Спасибо за ссылку. Это полезно, но мне не терпится написать «помощник», который перезаписывает исходное if, чтобы сделать его _собственным_ if. Я уверен, что это возможно. Любой уважающий себя шаблонизатор нуждается в правильном условном форматировании. Руль не должен быть исключением.

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

Все встроенные функции, если и т. Д., Определены через registerHelper. Проверять:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

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

Я никогда не говорил, что с «помощниками» что-то не так. Просто, на мой взгляд, правильный if-оператор не должен быть расширением. Помощник (опять же, на мой взгляд) - это что-то специфическое для CMS или чего-то подобного. Помощник - это нечто, выполняющее особую операцию или условие. То, что не для всех. То есть, если он определен вне основной библиотеки. Возможно, немного похоже на плагины jQuery: самые элементарные вещи встроены, то, с чего можно начать. Но то, что не для всех, определяется вне основной библиотеки (то есть в плагинах). В терминах jQuery простая функция-фильтр не будет плагином.

Оператор if (на мой взгляд) неприменим к этой парадигме плагинов. Это элементарно, это один из самых основных принципов программирования и шаблонизаторов ...

Тогда быстрое продолжение. Вот что у меня есть на данный момент:

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

Используя это в моем шаблоне, например {{#when riskfactor eq 0}}...{{/when}} я получаю в своей консоли массив [6, undefined, 0, function()] . Последний, который я получаю. Это то, что мне нужно вызвать для обработки содержимого этого блока when. Первые три ... ну не очень. Цифра «6» - это фактически значение «фактора риска». Хорошо, я могу с этим согласиться. Неопределенное выше меня. Я думаю, что Handlebars пытается оценить его на входном объекте, но это не сработает. Я хочу получить вещи, которые на самом деле _в_ шаблоне, потому что подобные значения не имеют ничего общего с моим объектом.

Я ожидал чего-то вроде ["riskfactor", "eq", "0", function()] . Только тогда моя функция сможет продолжить и обработать это. Как я собираюсь сделать это с "undefined"?

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

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

Чтобы ответить на ваш последний вопрос, вы хотите использовать это:

 {{#when "riskfactor" "eq" 0}}...{{/when}}

Выражения Handlebars - это либо имена переменных, либо строки. Если это имя переменной, при поиске в текущем контексте вы получите значение переменной, а не имя.

Это выходит за рамки Handlebars, как отмечали некоторые.

Нет.
ЛЮБАЯ система шаблонов может выполнять простой сравнительный блок if-else, а Handlebars - нет. Это делает Handlebars либо до смешного неполным, либо некомпетентными его создателями (что маловероятно), либо системой с туманным взглядом на задачи системы шаблонов.

ТОГДА НЕ ИСПОЛЬЗУЙТЕ БЕЗЛОГИЧЕСКИЙ ШАБЛОННЫЙ ДВИГАТЕЛЬ. KTHXBAI!

Понятно. Тудлс.

@thany , @andriijas, наверное, был немного резковат, но он прав. Руль задуман как лишенный логики. Вы определенно можете сделать велосипед с мотором, но многие компании предпочитают выпускать только безмоторные велосипеды. Точно так же вы можете создать систему шаблонов с большей логикой, но Handlebars не пытается этого сделать. Извините, это не то, что вы искали.

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

Кстати, если вы хотите злиться на машину и сделать это, вы можете создать помощника, который принимает предикат в виде строки, а затем оценивает его (и делает это дважды еретическим: smile_imp :):

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thany посмотрите на это с точки зрения передовой практики, ваш Back-end должен обслуживать данные со всей логикой, уже вычисленной. Front-end (шаблон) должен просто отображать его ... если у вас есть хорошее JSON-представление ваших backend-объектов, чем 95 % случаев могут быть удовлетворены сборкой в ​​условных выражениях http://handlebarsjs.com/#conditionals

Серьезно, не ВСЕ (или даже 95%) принимаемые решения ориентированы на серверную часть. Например, чтобы определить, какое имя класса отображать, вполне разумно принять это решение в шаблоне. Что-то подобное на 100% привязано к интерфейсу / шаблону. Бэкэнд не заботится о том, какое имя класса отображается. А как насчет единственного / множественного числа? Это еще одна вещь, которую нельзя сделать с блоком if.

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

Вы также можете поместить HTML в бэкэнд, если каждое решение, необходимое для шаблона, требует еще одной модификации в бэкэнде. Это просто лишает шаблоны смысла. Решения, привязанные к бэкэнду, находятся на совершенно другом уровне. Блок if не обязательно является логическим. Это просто решение, что / как рендерить.

Я не могу поверить, что эта проблема требует такого долгого обсуждения, неужели правильный if-block действительно слишком много, чтобы о нем просить? :(

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

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

Но опять же, помощник, который я написал, состоял из трех строк кода:

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

Я согласен с @thany , я также не верю, что это что-то, что должно быть вне шаблона / представления.

почему именно в шаблоне не может быть логики? и как рули обеспечивают разделение логики и представления? у него все еще есть инструкция if , не так ли? Вы говорите, что оператор if который просто проверяет существование и / или «ложность», ничем не отличается от оператора if который проверяет (не) равенство или любое другое условие?

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

Итак, утверждение «отделяя логику от представления». ошибочен не только по причинам, указанным выше, но и потому, что вы не удаляете «логику» из шаблона, вы просто перемещаете ее в другую часть шаблона - то есть в помощник - и, возможно, вы получите повторное использование кода - что было бы хорошо - а, возможно, и нет, и в этом случае вы можете получить любое количество помощников, выполняющих почти / точно то же самое, что и другие помощники, из-за незначительной разницы, которая была бы лучше, если бы была правильная реализация if . насколько это хорошее дизайнерское решение?

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

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

Кто-нибудь вообще смотрел, как реализуется текущий if? (есть также, если только это не приятно)

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

Посмотрите, как легко расширить

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

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

@andriijas да, unless - это просто if с инвертированным результатом. Я не понимаю, как это что-то компенсирует. спасибо за ссылку репо помощников, я уже написал помощника, опять же, я не вижу, как это что-то компенсирует.

Руль чуть больше 10 КБ (сжатый), а swag чуть меньше 3 КБ (сжатый). Итак, вы добавляете библиотеку шаблонов размером 10 КБ в свою кодовую базу, и вам нужны еще 3 КБ, чтобы иметь возможность добавлять логику в свои шаблоны. логика, которую вы и еще несколько человек говорите, что в любом случае не должно быть в ваших шаблонах?

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

@andriijas Я смотрю на /lib/handlebars/base.js#L97 , но не совсем понимаю, что вы имеете в виду. Похоже, что существует некая форма его альтернативного использования, но в документации это не указано. Не могли бы вы объяснить?

@constantology некоторым людям может понадобиться еще 3kb, например вам и другим ребятам из этой ветки . Остальные из 3500, которые отметили это репо на github, вряд ли будут жаловаться, потому что они решили свои логические потребности, добавив помощников или выполнив это до рендеринга шаблонов.

@piksel то, на что вы смотрите, - это тот факт, что встроенный if является просто помощником, как и любой «аддон», с которым многие, похоже, сталкиваются с проблемами, думая, что помощники работают медленнее или что-то в этом роде.

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

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

@andriijas, который все еще не отвечает ни на один из моих вопросов ...

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

ps количество людей, которые отметили репо и / или используют библиотеку, не обязательно указывает на то, насколько хороша библиотека. пользователей Windows больше, чем у Mac / Linux вместе взятых, и - в зависимости от того, какой сайт статистики браузера вы просматриваете - все еще больше людей используют Internet Explorer 6, 7 и 8 вместе взятые, чем более современный браузер. это не делает Windows лучшей операционной системой, чем osx или linux, и не делает старые версии Internet Explorer лучше, чем современные стандарты и совместимые браузеры.

Мне все это обсуждение глупо. Есть помощник if , ЭТО ЛОГИКА. Так что весь аргумент без логики - сплошной обман. Это как если бы в машине были окна, которые только опускались, а люди жаловались и хотели, чтобы они тоже закатывались. И производитель сказал, что не собирался менять это, потому что эти автомобили следовали строгой философии отсутствия механически управляемых окон ... Либо вы поддерживаете это, либо нет. Реализация наполовину не должна оправдываться аргументами соломенного человека.

Я полностью согласен и понимаю, что в шаблонах нет бизнес- логики. Но если вы делаете очень тривиальные шаблоны ваш будет иметь некоторый вид логики там. Handlebars, очевидно, распознает это, поскольку существует помощник if . Работа над ограниченным помощником if путем добавления кучи логики представления в ваш код не является ответом, как указал @thany . Я делал это раньше, быстро становится уродливо.

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

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

красиво сказано. : ^)

@constantology doh , извините, думаю, мне следовало лучше прочитать прошлые комментарии. : /

Я согласен с @constantology

FWIW Я считаю Handlebars действительно элегантной и хорошо написанной библиотекой шаблонов.

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

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

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

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

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

для исходного вопроса помощник if со сравнением был бы неправильным. это распространенный сценарий и такие помощники, как:
{{#ifzero count}} Нет результатов {{/ ifzero}}
{{#ifsingular count}} 1 результат {{/ ifsingular}}
{{#ifplural count}} {{count}} результаты {{/ ifplural}}
был бы более полезным и переводил бы его на то, чем он действительно хочет заниматься. текущий синтаксис if полезен для (не) отображения пустых значений. тоже очень распространенный сценарий. если кому-то действительно нужен if со сравнением, очень вероятно, что это бизнес-логика, и он не должен делать это в шаблоне.

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

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

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

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

Существует множество шаблонных систем без логики, которые не предлагают сравнения. Например, в языках со строгой типизацией, таких как go, что вообще означает равенство? В шаблонах Go нет сравнений. Существуют реализации усов и ручек для разных языков, и они одинаковы.

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

Ну давай же.
Comaprisons не так уж и сложно. Это не ракетостроение (или операция на головном мозге).

В очень простых микро-шаблонах вам не нужна логика, но если она станет более сложной, вам понадобится логика в шаблонах. Есть такое понятие, как «бизнес-логика», а также «логика шаблона». Определение, что делать, когда есть только один предмет из чего-то, или два, или десять. Например, пейджинг. Разделители. Простые тексты «менее 50%» и «более 50%», и я мог бы продолжить.

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

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

«это может погубить продукты и даже компании»? Шутки в сторону?
Неправильная функциональность тоже может.

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

Если это ракетостроение: https://github.com/elving/swag

В субботу, 18 мая 2013 г., Тэни написал:

Ну давай же.
Comaprisons не так уж и сложно. Это не ракетостроение (или операция на головном мозге).

В очень простых микрошаблонах логика не нужна, но если она есть
более сложный, вам понадобится логика в шаблонах. Есть такой
вещь как «бизнес-логика», так и «шаблонная логика». Определение того, что
делать, когда есть только один предмет из чего-то, или два, или десять. Пейджинг, для
пример. Разделители. Простые тексты «менее 50%» и «более 50%», и я мог бы продолжить.

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

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

«это может погубить продукты и даже компании»? Шутки в сторону?
Неправильная функциональность тоже может.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/wycats/handlebars.js/issues/206#issuecomment -18104713.
.

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

@thany Я чувствую тебя и согласен с тобой.

Я думаю, что люди, стоящие за рулем, не хотят отказываться от этого, но, эй, я вам скажу потрясающие новости:
Вы можете _fork _ проект, добавить патч и использовать свой собственный форк.
Благодаря магии git, будет довольно легко не отставать от новых версий, просто git pull ing.

И подожди, станет лучше.

Если это окажется большой потребностью и в целом будет лучше, возможно, люди начнут использовать вашу вилку или, что еще лучше, ребята за рулем объединят вашу вилку обратно в origin / master: dancer:

есть хороший; D

Если бы я уделил себе время, конечно!

Я полностью согласен с @constantology. Безумие иметь шаблон без логики. И если вы хотите иметь шаблон без логики, почему вы помещаете туда утверждение: «если», которое представляет логику как опасность красного цвета ... Не имеет смысла. Я думаю, что базовая логика сравнения нужна как соль в супе. @mikeobrien : «

Есть что сказать о шаблонах без логики. Хотя я считаю, что проблема в том, что все здесь путают бизнес-логику с логикой представления. Бизнес-логике нет места в шаблонах. Период. А вот логика взглядов - это совсем другое дело. Я думаю, что Handlebars понимает это, поэтому они в первую очередь добавили if / else, они просто немного запутались на этом пути.

Мне нужно знать, есть ли в моем массиве данных один элемент или несколько, и в зависимости от этого я хочу объединить их запятыми или добавить к слову множественное число. С текущим блоком if я не могу этого сделать.

Вот почему я сделал этот запрос на перенос: https://github.com/wycats/handlebars.js/pull/566 и сопровождающий jsfiddle: http://jsfiddle.net/YsteK/

Этот запрос на перенос предоставляет новый помощник: ifTest, который принимает выражение javascript, которое оценивается так же, как javascript при задании контекста. Наслаждаться.

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

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

Handlebars.registerHelper ('ifCond', function (v1, v2, options) {
if (v1 === v2) {
вернуть options.fn (это);
}
return options.inverse (это);
});

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

Я хотел бы еще раз проголосовать либо за полное удаление if , или за разрешение if принимать некоторые базовые аргументы сравнения, например eq , ne , gt и т. Д. В итоге вы получите {{#if arg1 eq arg2}} . Конечно, полное удаление if имело бы больше смысла для вашей философии «без логики в шаблонах» (сейчас это больше похоже на «отсутствие логики в шаблонах _ большую часть времени_, но _ иногда_ это нормально»).

Без помощника я все время занимаюсь такими вещами:

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

Кажется глупым добавлять все эти дополнительные свойства к объекту.

webgovernor - Проверьте это: http://jsfiddle.net/YsteK/

Это помощник, который включает эту функцию. Требуется выражение javascript, которое оценивается так же, как javascript с учетом контекста. Наслаждаться.

Спасибо, tniswong, это очень похоже на моего помощника. У меня проблема решена, я просто хотел подчеркнуть лицемерие догмы «без логики» Handlebars.

Без проблем. Я здесь с тобой. Я люблю рули, но без этого помощника они бесполезны.

Я отправил этот помощник как запрос на перенос, но он был отклонен. Поэтому я отправил еще один запрос на перенос, который удалил блок if. Также отклонено. /вздох

Хахаха. Github нужна кнопка для голосования.

Было отклонено? -_-

Упорство бессмысленной религии Handlebars поистине ошеломляет.

566 и # 568

Он упомянул, что может добавить его в README, но я не задерживаю дыхание.

+1 к этому! Аргххх!

FWIW, репозиторий Swag предоставляет помощники, которые добавляют сравнение, сортировку и другие полезные вещи. Я не строю ничего в Handlebars без него.

Тем не менее, я лично согласен с тем, чтобы Handlebars оставались как можно менее логичными, поскольку они сохраняют его чистоту, расширяемость и ремонтопригодность. Если вы хотите большего, внесите свой вклад в репо, например _Swag_, для вещей, выходящих за рамки проекта. Если сопровождающие этого проекта передумают, все, что потребуется, - это запрос на перенос: +1:

@aboutaaron Если вы собираетесь сделать такое заявление, как «позволять Handlebars оставаться как можно менее логичным, поскольку он сохраняет его чистоту, расширяемость и удобство обслуживания», вы должны по крайней мере иметь приличие, чтобы:

1. предоставить доказательство того, что руль не содержит логики. Если вы прочитали поток, то вы увидите, что уже было доказано, что handlebars содержит неполную логику в виде оператора if который проверяет только «правдивость», если вы не прочитали поток, то я предлагаю вам это сделать.
2. предоставить доказательство того, что дескрипторы, обеспечивающие неполную логику в форме оператора if который только проверяет «правдивость», каким-то образом «сохраняет его чистым, расширяемым и поддерживаемым».
   Разве это не противоречие? Если handlebars является расширяемым, не означает ли это, что было бы тривиально предоставить полную реализацию условных операторов?
   Как, например, handlebars, предоставляющие полный оператор if сделать его менее чистым, расширяемым и обслуживаемым, чем разработчик, использующий ручки и swag ?
   Можно утверждать, что использование хелперов swag сделает кодовую базу менее чистой, расширяемой и удобной в обслуживании, поскольку вам нужно использовать разные хелперы для каждого оператора сравнения, то есть gt , gte , is , isnt , lt , lte а также для каждого логического оператора, т.е. and , or .
   Как это сделать код более читабельным, чем если бы все это выполнялось так же, как это было бы внутри оператора if - на любом другом языке? Если бы это было так, то я бы предположил, что сами языки программирования покончат с условными операторами, которые проверяют что-либо, кроме «правдивости»? Я этого не вижу.

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

В заключение, тот факт, что существует несколько библиотек, которые стремятся добавить полноты к неполной реализации if в ручных управлениях - так или иначе - показывает, что существует потребность в этом типе функциональности в его основной. Посмотрите на сам язык JavaScript, Harmony представляет множество функций, которые были предоставлены сторонними библиотеками, итераторами, модулями, генераторами, классами, прокси и т. Д .; и DOM API также реализовал функции, которые были предоставлены сторонними библиотеками, querySelector [All], CORS, и есть даже реализация DOM Promises в chrome canary.

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

@constantology +1 Аминь.

Я только что прибыл сюда после того, как попробовал {{#if something> something_else}} и осознал всю правду этой ситуации. Тем не менее, я склонен согласиться с людьми, занимающимися рулем, в этом вопросе. Я использовал жидкость в течение долгого времени, и подобные цепочки комментариев неизбежно приводят к добавлению недоделанных функций, таких как математика и конкатенация строк, которые действительно были в бэкенде.

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

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

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

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

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

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

Теперь у меня нет проблем, потому что Swag мне поможет.
Однако я запутался, потому что помощник if по умолчанию был слишком простым.
Если вы говорите, что Hanlebars лишен логики, я сомневаюсь, что Handlebars нуждаются во встроенных помощниках.
Если бы у него не было встроенных помощников, я думаю, что мне было бы легче понять философию Handlebars.

Возможно, у меня нет хорошего представления о logic-less и business logic , я хочу сказать вам, что я думал.

Я считаю, что вы просто не можете рассматривать одно if / except (без условных выражений) как логику, поскольку это просто - в контексте без логики - средство для представления логических данных в виде "{{foo}}" синтаксис - это средство представления строковых данных.

Поэтому я думаю, что следует прекратить следующее поведение: «Если это без логики, почему здесь оператор if? HA-HA, мат !!!»

Затем измените его на "{{#exists}}" вместо "{{#if}}", потому что это имеет больше смысла.

5 октября 2013 г., в 10:52, cal127 [email protected] написал:

Я считаю, что вы просто не можете рассматривать одно if / except (без условных выражений) как логику, поскольку это просто - в контексте без логики - средство для представления логических данных в виде "{{foo}}" синтаксис - это средство представления строковых данных.

Поэтому я думаю, что следует прекратить следующее поведение: «Если это без логики, почему здесь оператор if? HA-HA, мат !!!»

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

: thumbsup: для изменения {{#if}} на {{#exists}} или {{#isTrue}}

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

Но, тем не менее, название «если» все же было бы более подходящим по историческим причинам. Реализация Handlebars синтаксически не отличается от любой другой реализации if, она соответствует старому синтаксису if ([predicate]) [do sth].

Отличие состоит в том, что [предикат] должен быть простой переменной типа bool, а не выражением. Но это не ограничение «если». Это более общее ограничение, вызванное отсутствием поддержки выражений интерпретатора Handlebars. (Я думаю, что именно поэтому Handlebars не имеет логики)

Это означает, что это «если» ничем не отличается от любого другого «если».

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

Назовите это {{#truthy}} и {{#falsey}} потому что это все, что делают {{#if}} и {{#unless}} .

Разработчикам: вытащите голову из песка. Шутки в сторону. Вы можете видеть, что существует потребность в правильном if-выражении (и я намерен использовать слово «требование» буквально), так что идите и реализуйте его, вместо того чтобы ныть по поводу бессмысленности. Если вы хотите, чтобы шаблоны не содержали логики, откажитесь от ВСЕЙ логики, включая {{#if}} и {{#each}} .

ПРОСТО реализуйте правильный if-оператор.
Люди, которые твердо верят в свою бессмысленность, не должны его использовать. Простой. В качестве. Что.

Я даже уже сделал для тебя работу.

https://github.com/wycats/handlebars.js/pull/566
https://gist.github.com/tniswong/5910264

5 октября 2013 г., в 15:20, thany [email protected] написал:

Назовите это {{#truthy}} и {{#falsey}}, потому что это все, что делают {{#if}} и ​​{{#unless}}.

Разработчикам: вытащите голову из песка. Шутки в сторону. Вы можете видеть, что существует потребность в правильном if-выражении (и я намерен использовать слово «требование» буквально), так что идите и реализуйте его, вместо того чтобы ныть по поводу бессмысленности. Если вы хотите, чтобы шаблоны не содержали логики, откажитесь от ВСЕЙ логики, включая {{#if}} и ​​{{#each}}.

ПРОСТО реализуйте правильный if-оператор. Люди, которые твердо верят в свою бессмысленность, не должны его использовать. Простой. В качестве. Что.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Спасибо за это, но решение должно быть в основном пакете. Термин «ifTest» предположительно используется только потому, что Handlebars перехватывает термин «если» до того, как вы сможете его использовать.

Другое дело, что ваш ifTest принимает строку и выполняет оценку этой строки во время выполнения, тогда как, если правильный if-блок будет в основном пакете, он может быть в скомпилированном шаблоне (что точно является одним из сильных очков - тот, который я не люблю выбрасывать за борт, используя eval() для ifs и elses)

Вы на 100% правы. Просто используя инструменты, доступные мне в то время.

Тем не менее, это работает.

5 октября 2013 г., в 15:41, thany [email protected] написал:

Спасибо за это, но решение должно быть в основном пакете. Кроме того, термин «ifTest» предположительно используется только потому, что Handlebars перехватывает термин «если» до того, как вы сможете его использовать. Другое дело, что ваш ifTest принимает строку и выполняет оценку этой строки во время выполнения, тогда как, если правильный if-блок будет в основном пакете, он может быть в скомпилированном шаблоне (что точно является одним из сильных очков - тот, который я не люблю выбрасывать за борт, используя eval () для ifs и elses)

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Просто наткнулся на эту ветку, когда искал сравнение в Handlebars. Я думаю, вам следует либо удалить / переименовать блоки {{#if}} и {{#each}} , либо реализовать правильный оператор if. Это базовая функция для каждого языка. Период. Если вам действительно нужны шаблоны без логики, почему бы вам просто не использовать вместо них Mustache?

Я понимаю, что среди разработчиков есть мнение, что шаблоны должны быть доступны для чтения не разработчикам (т.е. дизайнерам). Но A) я никогда не работал с дизайнером, где это было проблемой, и B) я думаю, что необходимо, чтобы общее решение было встроенным, и в качестве расширения вы можете использовать проверку только логических значений, так что у вас есть Выбор. Кроме того, добавление помощников, таких как {{#ifValueEqualsA}} и {{#ifValueEqualsB}} , заставит вас создать много шаблонного кода, который просто не нужен. Я работаю в небольшом мобильном проекте, и у меня уже есть 200 строк кода, которые просто добавляют сравнения для конкретных нужд. Это противоречит (надеюсь) мнению всех разработчиков, что все должно быть как можно более универсальным.

@ cal127 «Я считаю, что вы просто не можете рассматривать единственное if / except (без условных

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

@thany Rocks . Вчера я обратился к усам (еще один язык шаблонов без логики), и это был именно тот вопрос, который возник у меня в голове несколько мгновений спустя. Как программисты думали, что это круто? Это только усугубляет ситуацию. Я знаю, что парадигма программирования - это «отделение ДЕЛОВОЙ логики от логики ПРЕЗЕНТАЦИИ». Это def означает, что в представлении есть логика (например, представления, которые содержат / включают шаблоны в шаблоне, таком как mvc). Почему они пытаются это отрицать и убирают логику из презентации?

Сценарий: я запускаю цикл в представлении и хочу выполнить действие после x итераций. С рулем мне нужно создать помощника, а затем использовать его в цикле, верно? как это облегчит мою жизнь? Что случилось с if count == x ????? Что может быть лучше, чем использование такого языка, как php, для создания шаблонов? Как это помогает при проектировании с использованием логических шаблонизаторов?

Мне? Нет ничего лишенного логики для работы, ориентированной на логику. Извините!

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

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

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

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

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

Вы или никто другой не рассматривали ни один из многочисленных аргументов против этого в любой из многочисленных веток. Просто чтобы эти аргументы были понятны в этой ветке:
1) Вы нарушите существующую экосистему; что вызовет конфликты и переделки для команд, которые хотят обновиться, но имеют свои собственные IF в течение ~ 2 лет.
2) Существуют вспомогательные библиотеки, которые добавят, если вам нужно, вместе со всеми другими помощниками, которые вы попросите в следующий раз.
3) Как только будет решено добавить это «если», новым аргументом будет его реализация. Имя. Синтаксис. Аргументы. Вы можете пообещать, что будете довольны тем, что появится, но другие нет. Здесь сразу же появятся новые потоки, утверждающие, что это должно работать как-то иначе.
4) Существующее «если» - это именно то, что должно быть для -рендеринга-. «Отобразить X, если Y присутствует». Дело не в бизнес-логике; что должно произойти в вашей модели (я предлагаю Backbone, тогда у вас может быть все, что вы хотите, чтобы if было просто методом isXXX () в вашей модели).

Поскольку мы просим друг друга о чем-то, пожалуйста, не продолжайте это, если у вас нет достаточно веских технических аргументов для внесения серьезных изменений. Глупо расстраиваться - добавьте «ЕСЛИ», что хотите, и готово.

1) Нет, не будешь. Если вы ничего не сделаете, шаблоны должны продолжать работать. Конечно, все должно быть обратно совместимо. А даже если это не так, просто не обновляйтесь.
2) Оператор if является элементарным. То, что вы говорите, похоже на то, что колеса на машине теперь необязательны.
3) Синтаксис оператора if не имеет большого значения. Он есть у каждого языка программирования, и каждый из них делает одно и то же. Так что выберите один, и все будет хорошо. Что еще более важно, лучше иметь ЛЮБОЙ правильный if-оператор, чем то, что есть сейчас.
4) Неправильно, ищите вверх по "шаблонной логике".

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

Джордж Фрик -

1) Чем это отличается от обновления ЛЮБОЙ другой инфраструктуры или библиотеки, которые когда-либо существовали?
2) Вы правы. Однако ручное добавление этих основных функций не обязательно для чего-то столь фундаментального и необходимого.
3) Для этого нужны запросы на вытягивание.
4) Вы совершенно упустили суть. Никто в этой теме не выступает за бизнес-логику на уровне представления. Мы выступаем за ПОЛЕЗНУЮ логику отображения на уровне представления. Заданное «если» не является истинным «если», что сбивает с толку любого, кто хоть раз когда-либо использовал язык программирования. Это больше похоже на «существует».

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

22 ноября 2013 г. в 15:55 Джордж Фрик [email protected] написал:

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

Вы или никто другой не рассматривали ни один из многочисленных аргументов против этого в любой из многочисленных веток. Просто чтобы в этой ветке были ясны аргументы:
1) Вы нарушите существующую экосистему; что вызовет конфликты и переделки для команд, которые хотят обновиться, но имеют свои собственные IF в течение ~ 2 лет.
2) Существуют вспомогательные библиотеки, которые добавят, если вам нужно, вместе со всеми другими помощниками, которые вы попросите в следующий раз.
3) Как только будет решено добавить это «если», новым аргументом будет его реализация. Имя. Синтаксис. Аргументы. Вы можете пообещать, что будете довольны тем, что появится, но другие нет. Здесь сразу же появятся новые потоки, утверждающие, что это должно работать как-то иначе.
4) Существующее «если» - это именно то, что должно быть для -рендеринга-. «Отобразить X, если Y присутствует». Дело не в бизнес-логике; что должно произойти в вашей модели (я предлагаю Backbone, тогда у вас может быть все, что вы хотите, чтобы if было просто методом isXXX () в вашей модели).

Поскольку мы просим друг друга о чем-то, пожалуйста, не продолжайте это, если у вас нет достаточно веских технических аргументов для внесения серьезных изменений. Глупо расстраиваться - добавьте «ЕСЛИ», что хотите, и готово.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

@thany
Есть разница между опровержением аргумента и его отклонением. «НЕПРАВИЛЬНО» означает «НУ-У-У!».
Постарайтесь также не говорить об этом так лично.

@tniswong
1) Нет, это верно для любой структуры.
2) Если вы применяете это в общем смысле, Node должен включать все свои компоненты. Можно утверждать, что они являются фундаментальными или необходимыми, но это приведет к мысли, что группирование их всех вместе вне стандартной структуры является хорошей абстракцией и разделением. Многим проектам они просто не нужны, а другим нужны специальные версии. Таким образом, вы можете добавить стандартный набор, написать свой собственный или ничего не использовать. Нет (опять же) какой-либо технически обоснованной причины для включения всех этих помощников по умолчанию.
3) Ваше утверждение никоим образом не отрицает исходную точку зрения, на самом деле - вы ему помогаете. 20 запросов на исправление ошибок If. Готов поспорить, команде разработчиков понравится их пройти.
4) Точно, это «существует». Визуализируйте это, если он существует.
Когда вы не можете написать о «ником и никогда», для этого нужен единственный встречный пример. _ поднимает руку_.

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

1. Переименуйте if в exists и прекратите называть ручки управления "без логики" (потому что это не так).
2. Добавьте поддержку if чтобы он работал как оператор if .
3. Полностью удалить if .

Я был бы рад любому из этих вариантов.

Не забывай {{#unless}}

22 ноября 2013 г. в 16:40 Aaron M [email protected] написал:

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

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Я думаю, что на самом деле все это сводится к прекрасному изложению Аарона.

1. Существует лицемерие, с которым нужно бороться, утверждая, что он лишен логики, И снабжая его условием «если / если».
2. Данное «если» неверно.

Исправьте их обоих, и этот аргумент исчезнет.

22 ноября 2013 г. в 16:43 Тодд Нисвонгер [email protected] написал:

Не забывай {{#unless}}

22 ноября 2013 г. в 16:40 Aaron M [email protected] написал:

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

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

@georgefrick
Я отвергал его аргумент просто потому, что он уже миллион раз опровергался. Мы слишком долго это пережили, и это должно закончиться. Необходимо добавить оператор if, никто не будет ущемлен, и все будут счастливы. Не желать этого - то же самое, что не хотеть кондиционирования воздуха во ВСЕХ домах. Я буду судить о том, что я хочу в своем доме. Если он у вас, и вы этого не хотите, оставьте его. Просто как тот.

@webgovernor
Переименование не требуется. Правильный оператор if можно сделать полностью совместимым с текущим. В настоящее время это просто «if boolean then ...», и любой полнофункциональный оператор if будет делать именно это, только это логическое значение теперь может быть любым выражением, а не только одной переменной.

@tniswong
Как мило с их стороны, правда? Чтобы добавить грязный дополнительный тег, потому что блок if в том виде, в котором они реализованы, настолько упрощен, что не может даже отрицать выражение. Но в будущих Handlebars тег if может просто стать псевдонимом для «if not». Вроде как do .. пока по сравнению с while..do в программировании, где два существуют в первую очередь для удобства чтения, а не _ действительно_ по какой-либо технической причине.

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

@jeremiahlee Не уверен, согласны вы со мной или не согласны, я могу прочитать ваш комментарий в любом случае :)

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

Это заставило меня написать помощник под названием «when», который выполняет сравнения. По-прежнему нет правильной конструкции if-block, но для меня в то время достаточно близко. Тем не менее, это создало для меня много лишней работы.

@thany : Я согласен с тем, что в Handlebars должно быть встроено базовое сравнение двух значений. Шаблоны без логики также не должны лишаться сочувствия.

Я также буду голосовать за @thany и другие аргументы. Выражения if else слишком просты.
Условные классы и блоки select с предварительно выбранными option s должны выполняться с пакетом ручек по умолчанию.

С вложенными помощниками это больше не проблема, например

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

хороший пример @mmun : +1:

Немного странно, и я не вижу никаких логических комбинаторов ... Но, прежде всего, это не меняет общей точки зрения сопровождающих этого проекта, которая кажется нерушимой: «НЕТ ЛОГИКИ !! 11 !! 1! 1-дюймовый вид.