이것은 도우미에 의해 수행될 수 있습니다.
이것을 보십시오: http://kan.so/packages/details/handlebars-helpers
두 값을 비교할 수 있는 ifequal 도우미가 있습니다.
귀하의 요구 사항에 유사한 솔루션을 사용할 수 있습니다.

나는 그것이 두려웠다.
나는 도우미로 그런 일을 할 수 있다는 것을 알고 있습니다 ... 그러나, 내 말은, 물건을 비교하는 것은 매우 기본적이므로 기본 패키지에 있어야합니다.

그것이 패키지에 포함된다면 어쨌든 도우미가 될 것입니다.

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

@andriijas 맞습니다. 실제로 도우미가 될 것입니다.
링크 주셔서 감사합니다. 도움이 되지만 원본 if를 덮어쓰는 "helper"를 작성하여 _적절한_ if로 만들고 싶습니다. 나는 그것이 가능하다고 확신한다. 자체 존중하는 템플릿 엔진에는 적절한 조건부 서식이 필요합니다. 핸들바도 예외는 아닙니다.

템플릿에 비즈니스 로직을 적용하는 핸들바의 모든 것이 헬퍼라는 사실을 극복해야 합니다.

내장된 모든 if etc는 registerHelper를 통해 정의됩니다. 확인하다:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

따라서 도우미를 사용하는 데 "나쁜" 것은 없습니다. 핸들바는 거의 콧수염 템플릿 컴파일러이며 추가 비즈니스 로직을 얻기 위해 헬퍼를 사용합니다. 레일이나 기타에서 "도우미"라는 단어를 사용하는 데 나쁜 경험이 있다고 생각하는 경우.

나는 "도우미"에 문제가 있다고 말한 적이 없습니다. 내 생각에는 적절한 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-block의 내용을 처리하기 위해 호출해야 하는 것입니다. 처음 3개는... 글쎄요, 그렇게 많지는 않습니다. "6"은 실제로 "riskfactor"의 값입니다. 알겠습니다. 그렇게 하면 됩니다. 정의되지 않은 것은 저 너머에 있습니다. 핸들바가 입력 개체에서 이를 평가하려고 하지만 작동하지 않는다고 생각합니다. 이러한 값은 내 개체와 아무 관련이 없기 때문에 실제로 템플릿 _in_에 있는 것을 가져오고 싶습니다.

["riskfactor", "eq", "0", function()] 와 같은 것을 기대했습니다. 그래야만 내 기능이 진행하고 처리할 수 있습니다. "undefined"로 어떻게 합니까?

핸들바(및 기타 "논리 없는" 템플릿)의 철학은 템플릿에 도착하는 컨텍스트가 이미 완전히 처리되어야 한다는 것입니다. 애플리케이션의 내부 데이터 구조가 템플릿에 적합한 것과 완벽하게 일치하지 않는 경우(거의 매번 그럴 것입니다), 템플릿을 렌더링하기 전에 애플리케이션의 내부 데이터에서 템플릿 컨텍스트를 빌드하는 단계를 삽입해야 합니다. 구조.

사람들이 "논리와 프레젠테이션의 분리"에 대해 이야기할 때 그것이 의도라고 생각합니다. 핸들바를 MVC 시스템의 보기 구성 요소로 생각하십시오. 귀하의 모델이 이미 존재합니다. 지금 작성해야 하는 것은 컨트롤러뿐입니다(이 경우 모델에서 뷰로의 단방향 바인딩 집합입니다).

가장 최근 질문에 답하려면 다음을 사용합니다.

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

핸들바 표현식은 변수 이름 또는 문자열입니다. 변수 이름인 경우 이름이 아닌 현재 컨텍스트에서 조회할 때 변수 값을 얻습니다.

이것은 일부 사람들이 지적했듯이 핸들바의 영역을 벗어난 것입니다.

아니요.
모든 템플릿 시스템은 간단한 비교 if-else-block을 수행할 수 있지만 핸들바는 할 수 없습니다. 그것은 핸들바를 엄청나게 불완전하거나, 그 제작자가 무능하거나(그럴 것 같지 않음) 템플릿 시스템의 작업에 대한 흐릿한 관점을 가진 시스템으로 만듭니다.

그런 다음 LOGICLESS TEMPLATE ENGINE을 사용하지 마십시오. KTHXBAI!

알았어요. 두들.

@thany , @andriijas 는 아마도 약간 가혹했지만 그가 옳았습니다. 핸들바는 로직이 필요하지 않습니다. 모터가 있는 자전거는 분명히 만들 수 있지만 많은 회사에서 모터가 없는 자전거만 만드는 데 만족하고 있습니다. 마찬가지로, 더 많은 논리를 사용하여 템플릿 시스템을 만들 수 있지만 이는 핸들바가 하려고 하는 것이 아닙니다. 죄송합니다. 당신이 찾고 있던 것이 아닙니다.

if 도우미에서 @thany 와 함께해야 합니다. 모든 술어를 전달할 수 있어야 합니다. 실제로 사용을 제한할 수 없습니다. 나는 논리가 없는 템플릿 뒤에 숨은 철학을 이해하지만 독단적인 구현은 실제로 실용적이지 않습니다(따라서 도우미의 존재, 맞나요?). 나는 이것이 완전히 합리적인 가변 기어비를 추가하는 자전거 회사와 더 비슷하다고 말하고 싶습니다.

BTW, 만약 당신이 기계에 대해 분노하고 이것을 하고 싶다면, 당신은 술어를 문자열로 취하고 그것을 평가하는 도우미를 생성할 수 있습니다 (그리고 이것을 두 번 이단으로 만듭니다 :smiling_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 는 모범 사례 관점에서 그것을 살펴봅니다. 백엔드는 이미 파악된 모든 논리로 데이터를 제공해야 합니다. % 사례는 조건부 빌드로 만족할 수 있습니다 . http://handlebarsjs.com/#conditionals

진지하게, 내려진 모든(또는 95%) 결정이 백엔드 지향적인 것은 아닙니다. 예를 들어, 렌더링할 클래스 이름을 결정하려면 템플릿에서 해당 결정을 내리는 것이 완전히 합리적입니다. 그런 것은 프론트엔드/템플릿에 100% 묶여 있습니다. 백엔드는 어떤 클래스 이름이 렌더링되는지 신경 쓰지 않습니다. 또는 단수/복수 단어는 어떻습니까? 그것은 if 블록으로 할 수 없는 또 다른 일입니다.

내 생각에 백엔드는 이와 같은 풍부한 템플릿으로 작업할 때 데이터 및 데이터만 제공하는 책임이 있습니다. 백엔드가 템플릿이 결정할 수 있는 모든 상황에 대해 템플릿 파서에 미리 만들어진 변수를 제공해야 하는 경우(여기서 약간의 유연성을 고려하면) 변수의 양은 말할 것도 없고 엄청나게 복잡할 것입니다. 그들을 만드는 백엔드.

템플릿에 필요한 모든 결정이 백엔드에서 또 다른 수정이 필요한 경우 HTML을 백엔드에 넣을 수도 있습니다. 이는 템플릿 목적의 큰 부분을 제거합니다. 백엔드와 관련된 결정은 완전히 다른 수준에 있습니다. if 블록이 반드시 논리는 아닙니다. 무엇을/어떻게 렌더링할지 결정하는 것뿐입니다.

나는 이 문제가 그렇게 긴 토론을 필요로 한다는 것을 믿을 수 없습니다. 적절한 if 블록이 정말로 요구하기에는 너무 많은 것입니까? :(

나는 기본 비교 도우미 구현을 찬성하거나 반대하지 않을 것이지만, 이것은 도우미를 사용하거나 데이터 구조를 변경하지 않고는 템플릿을 렌더링할 수 없다고 생각하는 매우 실제적인 경우입니다.

    <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 문이 (에서) 평등 또는 기타 조건에 대한 검사?

유일한 — 실제 — 차이점은 다른 템플릿 라이브러리와 달리 핸들바가 "논리 없는" 논리를 가장 열악하거나 불완전하게 구현한다는 것입니다. 죄송하지만 완전히 말도 안되는 소리입니다. 논리를 제거하려면 if 문을 모두 제거해야 합니다. 하지만 핸들바에 여전히 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 뿐입니다. 나는 이것이 무엇을 보상하는지 알지 못합니다. 도우미 저장소 링크에 감사드립니다. 이미 도우미를 작성했지만 이것이 어떻게 보상되는지 모르겠습니다.

핸들바는 10kb 조금 넘고(minzipped) swag는 3kb 조금 넘습니다(minzipped). 따라서 코드베이스에 10kb 템플릿 라이브러리를 추가하고 템플릿에 논리를 추가하려면 3kb가 더 필요합니다. 당신과 몇몇 다른 사람들이 어쨌든 당신의 템플릿에 있어서는 안 된다고 말하는 논리는 무엇입니까?

이것은 내 질문에 대한 답이 아니며 실제로 if 문 블록에서 존재/거짓 이외의 조건부 테스트를 허용하지 않는 것이 무의미하다는 점을 증명하는 역할만 합니다.

@andriijas 보고 있는데 /lib/handlebars/base.js#L97 하지만 무슨 말인지 잘 모르겠습니다. 대체 사용의 어떤 형태가 있는 것처럼 보이지만 문서에는 이를 지정하지 않습니다. 설명해 주시겠습니까?

@constantology 어떤 사람들은 또 다른 3kb가 필요할 수 있습니다. 예를 들어 이 스레드의 당신과 다른 사람들. github에서 이 리포지토리에 별표를 표시한 나머지 3500명은 불평하지 않을 것입니다. 왜냐하면 템플릿을 렌더링하기 전에 도우미를 추가하거나 수행하여 논리 요구 사항을 해결했기 때문입니다.

@piksel 당신이보고있는 것은 내장 된 if가 많은 사람들이 문제가있는 것처럼 보이는 "애드온"과 같은 도우미 일 뿐이며 도우미가 느리거나 그 이상이라고 생각한다는 사실입니다.

프로젝트에서 도우미를 사용하는 데 아무런 문제가 없습니다. 한 프로젝트에서 일부 swag 도우미를 사용하여 내 view_helper 파일에 복사하여 3k 미만입니다.

한 백본 프로젝트에서 내 보기에 getTemplateData 메서드가 있습니다. 여기서 복잡한 논리를 템플릿을 더 깔끔하고 따르기 쉽게 만드는 더 쉬운 항목으로 요약합니다. 아, 또한 핸들바 템플릿보다 일반 자바스크립트를 단위 테스트하기 더 쉽습니다.

@andriijas 는 여전히 내 질문에 대답하지 않습니다...

이 시점에서 저는 제가 이미 말한 것을 반복할 것입니다. 따라서 제가 이미 질문한 일부 또는 모든 질문에 대해 실제로 합리적인 답변을 제공할 수 있다고 느끼신다면 저는 귀하가 무엇을 해야 하는지 매우 기쁘게 생각합니다. 말하다. :)

ps 리포지토리에 별표 표시한 사람 및/또는 라이브러리를 사용하는 사람의 수가 반드시 라이브러리가 얼마나 좋은지를 나타내는 것은 아닙니다. mac/linux를 합친 것보다 더 많은 Windows 사용자가 있으며(어떤 브라우저 통계 사이트를 보느냐에 따라) 최신 브라우저보다 Internet Explorer 6, 7, 8을 합친 사용자가 여전히 더 많습니다. 그것은 Windows를 osx 또는 Linux보다 더 나은 운영 체제로 만들지 않으며 이전 버전의 Internet Explorer를 최신 표준, 호환 브라우저보다 좋게 만들지 않습니다.

이 전체 토론은 나에게 무의미합니다. if 도우미가 있습니다. 그것은 논리입니다. 따라서 논리가 없는 전체 논증은 총체적 난국입니다. 마치 자동차에 창문이 굴러떨어지기만 하면 사람들이 불평하고 창문도 함께 굴려지기를 바라는 것과 같습니다. 그리고 제조사에서는 이 차가 기계적으로 제어되는 창문이 없다는 엄격한 철학을 따랐기 때문에 그것을 바꾸지 않을 것이라고 말했습니다... 당신이 그것을 지지하든 말든. 반쪽짜리 구현은 횡설수설한 주장으로 정당화되어서는 안 됩니다.

템플릿에 비즈니스 로직이 없다는 것에 전적으로 동의하고 이해합니다. 그러나 매우 사소한 템플릿을 수행하지 않는 한 거기에 보기 논리가 있을 것입니다. if 도우미가 존재하기 때문에 핸들바는 이를 분명히 인식합니다. 코드에 뷰 논리를 추가하여 햄스트링된 if 도우미를 해결하는 것은 @thany가 지적한 대로 답이 아닙니다. 예전에 해본적이 있는데 금방 질립니다.

@mikeobrien 예, 이전 댓글 에서 이미 언급했습니다. 그것은 답을 얻지 못한 많은 질문 중 하나였습니다.

템플릿에 비즈니스 로직이 없다는 것에 전적으로 동의하고 이해합니다. 그러나 매우 사소한 템플릿을 수행하지 않는 한 거기에 보기 논리가 있을 것입니다.

멋지게 넣어. :^)

@constantology doh, 죄송합니다. 과거 댓글을 더 잘 읽었어야

@constantology에 동의합니다.

FWIW 핸들바는 정말 우아하고 잘 작성된 템플릿 라이브러리입니다.

나는 블록과 도우미의 개념을 잘 이해하지만, 핵심 라이브러리에서 지원하여 더 우아하게 처리할 수 있는 작은 작업을 수행하는 도우미를 만드는 것이 논리와 프레젠테이션의 명확한 분리를 의미한다고 생각하지 않습니다. CSS는 조건문에 대한 지원을 추가하고 있으며 이 중 일부는 이미 미디어 쿼리를 통해 달성할 수 있습니다. 따라서 @mikeobrien이 말한 것처럼 단순히 "논리 보기"인 경우 순수 프리젠테이션 언어의 논리가 반드시

if / unless 블록에 조건부 검사가 없다는 이 한 가지 제한 사항으로 인해 우아하고 캡슐화된 템플릿을 만드는 것이 정말 어렵다고 생각합니다.

또한 템플릿을 통해 데이터를 구문 분석하기 전에 데이터를 사전 처리하는 방법이 있다는 데에도 동의합니다. 그러나 단순한 변경에 대해서만, 라이브러리의 의지에 따라 전체 데이터 구조를 다시 형식화하는 것은 아닙니다. 왜요?

1. 이는 복잡한 데이터 구조를 가져와 더 평평한 것을 생성해야 하는 경우 구문 분석의 전체 성능에 잠재적으로 영향을 미칠 수 있습니다.
2. 에 따라 1 어려워 리팩토링 - -, 그것은 잠재적으로보기 코드가 더 취성 변경할 수있는 원래의 스키마를 만든 경우.
3. 또한 원래 데이터 구조를 더 이상 뷰에 매핑하지 않으므로 양방향 데이터 바인딩이 더 까다로워질 수 있으므로 변경 사항을 추적하는 데 필요한 코드 양이 증가할 수 있습니다.

그것들은 내 머리 꼭대기에서 벗어 났고, 나는 그것을 뒷받침하기 위해 정량화 가능한 연구를 수행하지 않았지만 생각을위한 음식입니다. :^)

원래 질문의 경우 비교하는 도우미가 잘못된 경우입니다. 일반적인 시나리오이며 다음과 같은 도우미입니다.
{{#ifzero count}}결과 없음{{/ifzero}}
{{#ifsingular count}}결과 1개{{/ifsingular}}
{{#ifplural count}}{{count}}개 결과{{/ifplural}}
더 도움이 될 것이고 그가 정말로 하고 싶은 일을 번역할 것입니다. 현재 if 구문은 빈 값을 표시하는 데 유용합니다. 매우 일반적인 시나리오도 있습니다. 만약 누군가가 비교와 함께 if를 정말로 필요로 한다면 그것은 비즈니스 로직일 가능성이 매우 높으며 그는 템플릿에서 그것을 해서는 안 됩니다.

그것은 정말로 그것을 할 것입니다.
그러나 _원칙적으로_ 좋은 구석이든 아니든, 개발자를 특정 구석으로 몰아넣는 것은 엔진에 달려 있지 않다고 생각합니다. 비즈니스 로직인 개발자와 템플릿 로직인 개발자의 몫이라고 생각합니다.

즉, 비교를 할 수 없다는 한계가 순전히 기술적인 한계가 아니어서 어떻게든 패러다임으로 만든 것이 아니라면 말이다. 이는 필요할 경우 이러한 기능을 추가할 수 없음을 의미합니다. 그런 일이 없기를 바랍니다.

테스트 중입니다. 테스트. 이 논리를 쉽게 테스트할 수 없기 때문에 템플릿에 비교를 넣고 싶지 않습니다. 템플릿에 대한 데이터 포맷터를 통해 간단한 부울 값을 만들고 테스트하는 것이 셀레늄과 같은 것에 연결하여 테스트하는 것보다 훨씬 간단합니다.

이것은 단순한 이론이 아니며, 이것은 단지 '원칙'이 아닙니다. 템플릿에 비교조차 하고 이 논리를 테스트하지 않는 것은 아마도 실제 기술 부채 헛소리일 것입니다. 이러한 도우미를 작성하거나 사용하지 마십시오. 아직 핸들 바에 도우미를 사용하지 않았습니다. 그러나 도우미를 사용한 경우에는 도우미를 염탐하고 테스트하여 실행되었는지 확인할 수 있으므로 템플릿에 내장된 비교보다 낫습니다.

비교를 제공하지 않는 논리가 없는 템플릿 시스템이 많이 있습니다. 예를 들어 go와 같은 강력한 형식의 언어에서 평등은 무엇을 의미합니까? Go 템플릿에는 비교가 없습니다. 여러 언어에 콧수염과 핸들바 구현이 있으며 동일합니다.

템플릿에서 비교와 같은 논리를 제거해도 인생이 더 어려워지는 것이 아니라 더 쉬워집니다. 기술 부채는 농담이 아닙니다. 제품과 회사까지 망칠 수 있습니다.

어서 해봐요.
콤마프리즌은 그렇게 어렵지 않습니다. 로켓 과학(또는 뇌 수술)이 아닙니다.

아주 간단한 마이크로 템플릿에서는 논리가 필요하지 않지만, 더 복잡해지면 템플릿에 논리가 필요합니다. "템플릿 논리"뿐만 아니라 "비즈니스 논리"와 같은 것이 있습니다. 항목이 한 개, 두 개, 열 개뿐일 때 무엇을 할지 결정합니다. 예를 들어 페이징. 분할기. 간단한 "50% 미만" 및 "50% 초과" 텍스트, 계속할 수 있습니다.

다른 템플릿 엔진에도 논리가 없다는 사실이 맹목적으로 따라야 한다는 의미는 아닙니다. 내 생각에는 그들도 틀렸다.

사실, 비즈니스 로직이 아니기 때문에 비즈니스 로직에서 필요하지 않거나 원하지 않는 일종의 로직이 어느 시점에 있게 될 것입니다. 현재 또는 미래의 템플릿이 필요로 할 수 있는 모든 종류의 비교에 대해 부울 값을 입력해야 하는 동료 개발자에게 말할 수 없습니다.

"제품은 물론 회사까지 망칠 수 있다"? 진지하게?
부적절한 기능도 가능합니다.

대부분의 사람들이 필요로 하는 것을 배송하고 도우미를 추가하면 무엇이 문제입니까?
당신이 필요로하는 무엇을 위해? 모두가 이깁니다. 그렇게 어렵지 않고 로켓처럼
과학.

로켓 과학이라면 https://github.com/elving/swag

2013년 5월 18일 토요일에 Thany는 다음과 같이 썼습니다.

어서 해봐요.
콤마프리즌은 그렇게 어렵지 않습니다. 로켓 과학(또는 뇌 수술)이 아닙니다.

매우 간단한 마이크로 템플릿에서는 논리가 필요하지 않지만
더 복잡하면 템플릿에 논리가 필요합니다. 그런게 있다
"비즈니스 논리"와 "템플릿 논리"가 있습니다. 무엇을 할지 결정
물건이 한 개, 두 개, 열 개일 때 하세요. 페이징,
예시. 분할기. 간단한 "50% 미만" 및 "50% 초과" 텍스트, 계속할 수 있습니다.

다른 템플릿 엔진에도 로직이 없다는 사실,
맹목적으로 따라야 한다는 의미는 아닙니다. 그들도 내 생각이 틀렸어
의견.

사실, 어느 시점에서 당신은 당신이 방금
단순히 비즈니스가 아니기 때문에 비즈니스 논리에서 필요하거나 원하지 않습니다.
논리. 부울 값을 가져야 하는 동료 개발자에게 전달할 수 없습니다.
현재 또는 미래의 모든 상상할 수 있는 비교에 대해
템플릿이 필요할 수 있습니다.

"제품은 물론 회사까지 망칠 수 있다"? 진지하게?
부적절한 기능도 가능합니다.

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/wycats/handlebars.js/issues/206#issuecomment -18104713에서 확인하세요.
.

그것을 사용하지 않는 대부분의 사람들은 여기에 설명된 문제 때문일 수 있습니다. 논리가 없습니다. 그래서 물론 적극적으로 사용하는 대부분의 사람들은 그것에 대해 다소간 만족할 것입니다.

@thany 나는 당신을 느끼고 동의합니다.

핸들 바 뒤에 있는 사람들은 이것을 포기하고 싶지 않을 것이라고 생각합니다. 하지만 제가 여러분에게 말하려는 것은 놀라운 소식입니다.
프로젝트를 _fork _하고 패치를 추가하고 자신의 포크를 사용할 수 있습니다.
git의 마법으로 인해 git pull ing만으로도 새 버전을 따라잡기가 상당히 쉬워야 합니다.

그리고 기다리면 좋아집니다.

이것이 크게 필요하고 전반적으로 더 나은 경우 사람들이 포크를 사용하기 시작하거나 훨씬 더 나은 경우 핸들 바 뒤에있는 사람들이 포크를 다시 origin/master :dancer로 병합합니다.

잘 지내세요 ;D

나 자신에게 시간을 허락한다면, 확실히!

@constantology에 절대적으로 동의합니다. 미친 논리가 없는 템플릿이 있습니다. 그리고 논리가 없는 템플릿을 갖고 싶다면 왜 거기에 넣었는지: "if" 문은 논리를 빨간색 위험으로 나타내는 것... 말이 안 됩니다. 국물에 소금처럼 기본적인 비교 논리가 필요하다고 생각합니다. @mikeobrien : "

논리가 없는 템플릿에 대해 할 말이 있습니다. 하지만 문제는 여기 있는 모든 사람들이 비즈니스 논리와 보기 논리를 혼동하고 있다는 것입니다. 비즈니스 로직은 템플릿에 자리가 없습니다. 기간. 그러나 보기 논리는 완전히 다른 문제입니다. 나는 핸들바가 이것을 깨닫고 처음에 if/else를 추가했다고 생각합니다. 그들은 도중에 약간 혼란스러워했습니다.

내 데이터 배열에 항목이 하나 또는 여러 개 있는지 알아야 하며 이를 기반으로 쉼표로 결합하거나 단어에 복수를 추가하고 싶습니다. 현재 if 블록으로는 이것을 할 수 없습니다.

이것이 내가 이 pull request를 만든 이유입니다: https://github.com/wycats/handlebars.js/pull/566 및 동반 jsfiddle: http://jsfiddle.net/YsteK/

이 끌어오기 요청은 새로운 도우미 ifTest를 제공합니다. 이 도우미는 컨텍스트가 제공되는 자바스크립트와 마찬가지로 평가되는 자바스크립트 표현식을 사용합니다. 즐기다.

솔직히 이것은 기본적인 기능이기 때문에 프레임워크에 로직을 내장하지 않는다는 사고방식을 고수하고 싶다면(저에게는 완전히 비논리적으로 보입니다!) "if"와 같은 논리적 용어의 사용을 재고해야 한다고 생각합니다. .

"0" 및 "1"과 같은 항목을 부울 다른 값으로 비교할 때 매우 유용하기 때문에 이것을 많은 프로젝트에 추가하고 있습니다.

Handlebars.registerHelper('ifCond', function(v1, v2, 옵션) {
if(v1 === v2) {
반환 options.fn(이);
}
반환 options.inverse(this);
});

기존 "if" 기능이 작동하는 방식으로 작동하도록 하는 것이 완전히 공정하다고 생각하지만, 영어를 선호하고 다른 단어를 선택합니다(또는 사람들이 기대하는 대로 작동하도록 하는 것). 다른 컨텍스트에서 true if 문처럼 작동하지 않을 때 "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/

이 기능을 활성화하는 것은 도우미입니다. 자바 스크립트가 컨텍스트를 제공하는 것처럼 평가하는 자바 스크립트 표현식이 필요합니다. 즐기다.

고마워 tniswong, 내 도우미와 매우 비슷합니다. 나는 문제를 해결했고 핸들바 "논리 없는" 도그마의 위선을 강조하고 싶었습니다.

괜찮아요. 내가 바로 거기에 있어. 핸들바를 좋아하지만 이 도우미가 없으면 거의 쓸모가 없습니다.

이 도우미를 pull 요청으로 제출했지만 거부되었습니다. 그래서 if 블록을 제거한 또 다른 풀 리퀘스트를 제출했습니다. 또한 거부되었습니다. /한숨을 쉬다

ㅋㅋㅋㅋ Github에는 찬성 버튼이 필요합니다.

거절당했어? -_-

Handlebars의 논리가 없는 종교의 집요함은 정말 놀랍습니다.

566 및 #568

그는 그것을 README에 추가할 수 있다고 언급했지만 나는 숨을 죽이고 있지 않습니다.

이것에 +1! 으악!

FWIW, Swag 저장소는 비교, 정렬 및 기타 멋진 기능을 추가하는 도우미를 제공합니다. 핸들바 없이는 아무것도 만들지 않습니다.

즉, 개인적으로 핸들바를 깨끗하고 확장 가능하며 유지 관리할 수 있도록 유지하기 때문에 가능한 한 논리가 없는 상태로 유지하는 데 동의합니다. 더 많은 것을 원하면 프로젝트 범위를 벗어난 항목에 대해 _Swag_와 같은 리포지토리에 기여하세요. 이 프로젝트의 관리자가 마음을 바꾸면 pull 요청만 하면 됩니다.+1:

@aboutaaron "핸들

1. 핸들 바에 논리가 없다는 증거를 제공하십시오. 스레드를 읽었다면 핸들바에 "진실성"만 확인하는 if 구문의 불완전한 논리가 포함되어 있다는 것이 이미 입증되었음을 알 수 있습니다. 스레드를 읽지 않았다면 저는 그렇게 할 것을 제안할 것입니다.
2. 핸들바가 "진실성"만 확인하는 if 명령문의 형태로 불완전한 논리를 제공한다는 증거를 제공합니다.
   이것은 모순이 아닙니까? 핸들바를 확장할 수 있다면 조건문을 완벽하게 구현하는 것이 간단하지 않을까요?
   예를 들어, 완전한 if 문을 제공하는 핸들바는 핸들바 AND swag를 사용하는 개발자보다 어떻게 덜 깨끗하고 확장 가능하며 유지 관리가 용이합니까?
   swag 도우미를 사용하면 각 비교 연산자(예: gt , gte , is 에 대해 다른 도우미를 사용해야 하므로 코드베이스가 덜 깨끗하고 확장 가능하며 유지 관리가 용이하지 않다고 주장할 수 있습니다. is , isnt , lt , lte 뿐만 아니라 각 논리 연산자(예: and , or .
   다른 언어에서 if 문 내에서 이 모든 작업을 동일하게 수행하는 것보다 코드를 더 읽기 쉽게 만드는 방법은 무엇입니까? 이것이 사실이라면 프로그래밍 언어 자체가 "진실성" 이외의 것을 확인하는 조건문을 없앨 것이라고 가정할 것입니까? 나는 이것이 일어나는 것을 보지 못한다.

우연히 "템플릿에 비즈니스 로직을 넣어라"는 지겹고 입증되지 않은 주장을 사용하려는 경우에는 사용하지 마십시오. 이것은 이미 이 스레드에서 여러 번, 여러 사람에 의해 해결되었습니다. 동시에 그것이 유효한 주장이라고 생각하는 것이라면 이전 진술과 모순되는 swag 라이브러리를 사용할 필요가 없습니다.

결론적으로 핸들바에서 if 의 불완전한 구현에 완전성을 추가하려는 라이브러리가 여러 개 있다는 사실은 어떤 식으로든 이러한 유형의 기능이 필요하다는 것을 보여줍니다. 핵심. JavaScript 언어 자체를 보면 Harmony는 타사 라이브러리, 반복자, 모듈, 생성기, 클래스, 프록시 등에서 제공한 많은 기능을 도입하고 있습니다. 그리고 DOM API는 또한 타사 라이브러리인 querySelector[All], CORS에서 제공하는 기능을 구현했으며 심지어 크롬 카나리아에서 DOM Promises를 구현했습니다.

"핸들바를 깨끗하고 확장 가능하며 유지 관리할 수 있기 때문에 가능한 한 논리가 없는 상태로 유지"한다는 증거는 없습니다. 동시에, 다른 사람들과 저는 이 스레드의 이전 의견에서 핸들바가 완전한 if 구현을 제공하면 개발자에게 템플릿을 읽고 유지 관리하기가 더 쉽습니다.

@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}}

이 두 예제를 뒷받침하는 코드를 작성하는 방법에는 상당히 큰 차이가 있습니다. 둘 중 하나를 선택할 수 있는 유연성이 있으면 정말 좋을 것입니다. 나는 또한 첫 번째가 두 번째보다 더 많은 논리를 포함하는 방법을 실제로 알지 못합니다.

이 스레드가 말하는 것과 똑같은 것을 느꼈습니다. 그러다가 이 스레드를 찾았습니다.
그래서 핸들바의 철학을 이제서야 이해한 것 같습니다.
그러다 Swag와 같은 도우미 컬렉션이 필요하다는 것을 알게 되었습니다.

이제 Swag가 도와줄 것이기 때문에 문제가 없습니다.
그런데 기본 if 도우미가 너무 단순해서 혼란스러웠습니다.
Hanlebars가 논리가 없다고 말하면 Handlebars에 내장 도우미가 필요한지 의심됩니다.
빌트인 헬퍼가 없었다면 핸들바의 철학을 좀 더 쉽게 이해할 수 있었던 것 같아요.

logic-less 및 business logic 에 대해 잘 이해하지 못할 수 있습니다. 제 생각을 말씀드리고 싶습니다.

논리가 없는 컨텍스트에서 "{{foo}}"와 같이 부울 데이터를 나타내는 수단이기 때문에 단일 if/unless(조건부 제외)를 논리로 고려할 수는 없다고 생각합니다. 구문은 문자열 데이터를 나타내는 수단입니다.

그래서 나는 다음과 같은 행동을 멈춰야 한다고 생각한다. "논리가 없다면 왜 if 문이 있지? HA-HA, 체크메이트!!!"

그런 다음 "{{#if}}" 대신 "{{#exists}}"로 변경하는 것이 더 합리적입니다.

2013년 10월 5일 오전 10시 52분에 cal127 [email protected]에서 다음과 같이 썼습니다.

논리가 없는 컨텍스트에서 "{{foo}}"와 같이 부울 데이터를 나타내는 수단이기 때문에 단일 if/unless(조건부 제외)를 논리로 고려할 수는 없다고 생각합니다. 구문은 문자열 데이터를 나타내는 수단입니다.

그래서 나는 다음과 같은 행동을 멈춰야 한다고 생각한다. "논리가 없다면 왜 if 문이 있지? HA-HA, 체크메이트!!!"

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

:thumbsup: {{#if}}를 {{#exists}} 또는 {{#isTrue}}로 변경

더 합리적인 이름을 찾을 수 있다는 데 동의합니다. 'exists'는 그것을 할 것이고, 나의 제안은 'true' 또는 'on'이 될 것입니다.

그러나 그럼에도 불구하고 '만약'이라는 이름은 역사적 이유 때문에 여전히 더 적절할 것입니다. 핸들바의 if 구현은 구문적으로 다른 if 구현과 다르지 않으며 이전 "if ([predicate]) [do sth]" 구문을 따릅니다.

다른 점은 [predicate]는 베어 bool 변수여야 하며 표현식이 될 수 없다는 것입니다. 그러나 이것은 '만약'의 한계가 아닙니다. 이것은 Handlebars 인터프리터의 표현에 대한 지원 부족으로 인해 발생하는 보다 일반적인 제한 사항입니다. (정확히 이것이 핸들바를 논리가 없는 btw로 만드는 것입니다. 제 생각에는)

즉, 이 '만약'은 다른 '만약'과 다르지 않습니다.

그리고 'if'의 이름을 변경하려는 시도는 일부 사람들에게 이단으로 간주될 수 있습니다. 내가 경고하지 않았다고 말하지 마십시오.

{{#truthy}} 및 {{#falsey}} 라고 부르십시오. {{#truthy}} {{#if}} 및 {{#unless}} 가 하는 모든 일이기 때문입니다.

개발자에게: 모래에서 머리를 빼십시오. 진지하게. 적절한 if 문에 대한 요구가 있음을 알 수 있습니다(그리고 저는 '요구'라는 단어를 문자 그대로 사용하려고 합니다). 따라서 논리가 없다고 징징거리지 말고 실행하십시오. 템플릿을 논리 없이 만들려면 {{#if}} 및 {{#each}} 포함한 모든 논리를 사용하지 마십시오.

적절한 if 문을 구현하기만 하면 됩니다.
자신의 논리가 없다고 굳게 믿는 사람들은 그것을 사용하지 않기로 선택해야 합니다. 단순한. 같이. 저것.

나는 이미 당신을 위해 일했습니다.

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

2013년 10월 5일 오후 3시 20분에 Thany [email protected]에서 다음과 같이 썼습니다.

{{#truthy}} 및 {{#falsey}}라고 부르세요. 그게 {{#if}} 및 {{#unless}}의 전부이기 때문입니다.

개발자에게: 모래에서 머리를 빼십시오. 진지하게. 적절한 if 문에 대한 요구가 있음을 알 수 있습니다(그리고 저는 '요구'라는 단어를 문자 그대로 사용하려고 합니다). 따라서 논리가 없다고 징징거리지 말고 실행하십시오. 템플릿을 논리 없이 만들려면 {{#if}} 및 {{#each}}를 포함한 모든 논리를 사용하지 마세요.

적절한 if 문을 구현하기만 하면 됩니다. 자신의 논리가 없다고 굳게 믿는 사람들은 그것을 사용하지 않기로 선택해야 합니다. 단순한. 같이. 저것.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

감사합니다. 하지만 솔루션은 핵심 패키지에 있어야 합니다. "ifTest"라는 용어는 아마도 핸들바가 "if"라는 용어를 사용하기 전에 가로채기 때문일 것입니다.

또 다른 점은 ifTest가 문자열을 가져와 런타임에 해당 문자열을 평가하는 반면 적절한 if-block이 핵심 패키지에 있으면 컴파일된 템플릿에 있을 수 있다는 것입니다(정확히 Handlebars의 강력한 포인트 - if 및 else에 eval() 를 사용하여 배 밖으로 던지는 것을 좋아하지 않습니다.

당신이 100% 맞습니다. 그 당시 사용 가능한 도구를 사용하는 것뿐입니다.

어쨌든 작동합니다.

2013년 10월 5일 오후 3시 41분에 Thany [email protected]에서 다음과 같이 썼습니다.

감사합니다. 하지만 솔루션은 핵심 패키지에 있어야 합니다. 또한 "ifTest"라는 용어는 아마도 핸들바가 "if"라는 용어를 사용하기 전에 가로채기 때문일 것입니다. 또 다른 점은 ifTest가 문자열을 가져와 런타임에 해당 문자열을 평가하는 반면 적절한 if-block이 핵심 패키지에 있으면 컴파일된 템플릿에 있을 수 있다는 것입니다(정확히 Handlebars의 강력한 포인트 - if 및 else에 eval()을 사용하여 배 밖으로 던지는 것을 좋아하지 않습니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

Handlebars에서 비교를 검색하는 동안 이 스레드를 우연히 발견했습니다. {{#if}} 및 {{#each}} 블록을 제거하거나 이름을 바꾸거나 적절한 if 문을 구현해야 한다고 생각합니다. 모든 언어의 기본 기능입니다. 기간. 정말 논리가 없는 템플릿을 원한다면 Mustache를 대신 사용하는 것이 어떻습니까?

템플릿은 개발자가 아닌 사람(예: 디자이너)도 읽을 수 있어야 한다는 개발자 의견이 있는 것으로 알고 있습니다. 그러나 A) 나는 이것이 문제가 되는 디자이너와 함께 일한 적이 없으며 B) 접근 방식은 기본 제공되는 일반 솔루션을 사용할 수 있어야 하며 확장으로 부울 전용 검사를 사용할 수 있어야 한다고 생각합니다. 선택. 또한 {{#ifValueEqualsA}} 및 {{#ifValueEqualsB}} {{#ifValueEqualsA}} 와 같은 도우미를 추가하면 단순히 필요하지 않은 상용구 코드를 많이 생성해야 합니다. 나는 그다지 크지 않은 모바일 프로젝트에서 일하고 있으며 특정 요구 사항에 대한 비교를 추가하는 코드가 이미 200줄 있습니다. 이는 모든 개발자가 가능한 한 일반적이어야 한다는 사고방식에 반하는 것입니다.

@ cal127 "나는 당신이 단순히 하나의 if/unless(조건부 없이)를 논리로 고려할 수 없다고 믿습니다." - 그렇다면 무엇이 문제입니까? 부울 값을 확인하는 것보다 표현식을 확인하는 것이 더 논리적인 이유는 무엇입니까? 수표입니다. 기간. 그것이 여기서 수행되는 논리이며 표현식이 아닙니다(부울 값은 표현식이기 때문에). 물론 표현식이 비즈니스가 아니라 UI 로직을 나타낸다고 가정합니다.

논리가 없는 템플릿 엔진에 대한 아이디어가 이미 죽어가는 것 같아 유감입니다...나는 이것이 앞으로도 계속될 것이라고 생각하지 않습니다. 개발자는 더 복잡하지 않고 더 쉽고 빠르게 작업을 수행할 수 있는 도구가 필요합니다.

@thany 바위. 나는 어제 콧수염(또 다른 논리가 없는 템플릿 언어)에 대해 나왔고 이것은 정확히 몇 분 후에 내 머리에 떠오른 질문이었습니다. 프로그래머가 어떻게 이것이 멋지다고 생각했을까요? 이것은 문제를 악화시킬 뿐입니다. 내가 아는 프로그래밍 패러다임은 "BUSINESS 논리와 PRESENTATION 논리의 분리"입니다. 그 def는 프레젠테이션에 논리가 있음을 의미합니다(예: mvc와 같은 패턴의 템플릿을 포함/포함하는 보기). 어떻게 그들은 그것을 부정하고 프레젠테이션에서 논리를 제거하려고 합니까?

시나리오: 보기에서 루프를 실행 중이고 x 반복 후에 작업을 수행하고 싶습니다. 핸들 바를 사용하면 이제 도우미를 만든 다음 루프에서 사용해야 합니까? 이것이 어떻게 내 삶을 더 쉽게 만들어 줍니까? count==x라면 어떻게 되었나요????? 템플릿에 PHP 자체와 같은 언어를 사용하는 것보다 그게 더 낫습니까? 논리적 템플릿 엔진을 통해 설계하는 데 어떻게 도움이 됩니까?

나? 논리 지향적인 작업에는 논리가 없는 것이 없습니다. 죄송합니다!

나는 당신이 얼마나 무지할 수 있는지 믿을 수 없습니다. 그것은 현실이 아니라 완전한 신화, 오류, 거짓 종교입니다. 몇 줄 이상의 템플릿은 전혀 논리적이지 않습니다. 단순히 실용적이지 않습니다.

이제 이러한 믿음을 사용자에게 적용하는 것은 전적으로 귀하의 결정입니다. 그러나 논리에 대한 요구를 계속 무시하는 것은 어리석음과 무지의 증거입니다. 특히 이 특별한 경우에는 이미 가능하지만 아주 적은 양의 논리가 있기 때문입니다.

다시 한 번 재검토를 촉구합니다. 아니, 잠깐, 재고하지 마십시오. 듣고 옳은 일을 하십시오. 템플릿에 그런 어리석은 논리를 원하지 않는 사람들은 논리를 사용하지 않기 위해 계속해서 사악한 방식을 계속하고 온갖 종류의 고리를 건너뛸 수 있습니다.

적절한 비교를 수행하기 위해 if 블록을 확장해도 현재 사용이 중단되지 않습니다. 아직 논리적인 빛을 보지 못한 사람들에게는 문제가 되지 않을 것입니다. 그런 사람들은 그대로 계속 코딩할 수 있습니다.

그것은 멋에 관한 것이 아닙니다. 당신 자신은 논리와 표현의 분리를 논증으로 사용하고 그것을 무시하고 당신의 삶을 단순화하기를 요청합니다. 표준 핸들바 템플릿 라이브러리를 프로젝트에 추가하거나 직접 작성할 수 있습니다.

당신이나 다른 누구도 수많은 스레드에서 이에 반대하는 수많은 주장을 다루지 않았습니다. 이 스레드에서 이러한 인수가 명확하도록:
1) 기존 생태계를 교란할 것입니다. 업데이트를 원하지만 ~2년 동안 자체 IF를 갖고 있던 팀에게 충돌과 재작업이 발생합니다.
2) 다음에 요청할 다른 모든 도우미와 함께 필요한 경우 추가할 기존 도우미 라이브러리가 있습니다.
3) 이 'if'를 추가하는 데 동의하는 즉시 새 인수는 이를 구현합니다. 이름. 통사론. 인수. 그것이 나타나면 만족하겠다고 약속할 수 있지만 다른 사람들은 그렇지 않을 것입니다. 다른 방식으로 작동해야 한다고 주장하는 새 스레드가 즉시 여기에 있을 것입니다.
4) 존재하는 'if'는 정확히 -rendering-을 위해 있어야 하는 것입니다. "Y가 있는 경우 X 표시". 이것은 비즈니스 로직에 관한 것이 아닙니다. 이것은 당신의 모델에서 일어나야 하는 일입니다(저는 Backbone을 제안합니다. 그러면 당신은 당신의 모델에서 isXXX() 메소드가 되기 위해 당신이 원하는 무엇이든 가질 수 있습니다).

우리는 서로에게 무언가를 요구하고 있으므로 주요 변경 사항에 대한 기술적인 논의가 충분하지 않은 경우 계속하지 마십시오. 좌절하는 것은 어리석은 일입니다. 원하는 'IF'를 추가하고 완료하세요.

1) 아니요. 아무 것도 하지 않으면 템플릿이 계속 작동해야 합니다. 물론 모든 것이 이전 버전과 호환되어야 합니다. 그렇지 않은 경우에도 단순히 업그레이드하지 마십시오.
2) if 문은 기본입니다. 당신이 말하는 것은 자동차의 바퀴가 이제 선택 사항이라는 것입니다.
3) if 문의 구문은 거의 중요하지 않습니다. 모든 단일 프로그래밍 언어에는 하나가 있으며 모든 언어는 정확히 동일한 작업을 수행합니다. 따라서 하나를 선택하면 괜찮을 것입니다. 더 중요한 것은 적절한 if 문을 갖는 것이 지금보다 낫다는 것입니다.
4) 틀립니다. "템플릿 논리"를 위쪽으로 검색하십시오.

당신의 마지막 입장에 관해서는, 주장이 _있어_ 했고, 건전합니다. 그것은 몇 번이고 거듭거듭 논쟁이 되었지만, 그것은 정말로 종교처럼 보입니다. 깨지지 않으면서도 너무 약합니다.

조지 프릭 -

1) 이것이 지금까지 존재한 다른 프레임워크나 라이브러리를 업그레이드하는 것과 어떻게 다릅니까?
2) 당신 말이 맞아. 그러나 이러한 기본 기능을 수동으로 추가하는 것이 그렇게 기본적이고 필요한 것에는 필요하지 않습니다.
3) 그것이 바로 풀 리퀘스트를 위한 것입니다.
4) 요점을 완전히 놓쳤습니다. 이 스레드의 누구도 보기 계층의 비즈니스 논리에 대해 논쟁하지 않습니다. 우리는 뷰 레이어에서 USEFUL 디스플레이 로직에 대해 논쟁하고 있습니다. 주어진 "if"는 true가 아니므로 프로그래밍 언어를 사용한 적이 있는 사람에게는 혼동을 줍니다. 그것은 "존재한다"에 가깝다.

이것을 추가하면 사람들이 템플릿에서 비즈니스 로직을 사용하게 될 것이라고 생각한다면, 당신이 어리석은 것을 고칠 수 없기 때문에 아마도 당신이 옳을 것입니다. 누군가가 나쁜 일을 할 수 있다고 해서 그 과정에서 다른 사람들이 좋은(그리고 필요한) 일을 하는 것을 막아야 한다는 의미는 아닙니다.

2013년 11월 22일 오후 3시 55분에 George Frick [email protected]이 다음과 같이 썼습니다.

그것은 멋에 관한 것이 아닙니다. 당신 자신은 논리와 표현의 분리를 논증으로 사용하고 그것을 무시하고 당신의 삶을 단순화하기를 요청합니다. 표준 핸들바 템플릿 라이브러리를 프로젝트에 추가하거나 직접 작성할 수 있습니다.

당신이나 다른 누구도 수많은 스레드에서 이에 반대하는 수많은 주장을 다루지 않았습니다. 이 스레드에서 인수가 명확하도록 하기 위한 것입니다.
1) 기존 생태계를 교란할 것입니다. 업데이트를 원하지만 ~2년 동안 자체 IF를 갖고 있던 팀에게 충돌과 재작업이 발생합니다.
2) 다음에 요청할 다른 모든 도우미와 함께 필요한 경우 추가할 기존 도우미 라이브러리가 있습니다.
3) 이 'if'를 추가하는 데 동의하는 즉시 새 인수는 이를 구현합니다. 이름. 통사론. 인수. 그것이 나타나면 만족하겠다고 약속할 수 있지만 다른 사람들은 그렇지 않을 것입니다. 다른 방식으로 작동해야 한다고 주장하는 새 스레드가 즉시 여기에 있을 것입니다.
4) 존재하는 'if'는 정확히 -rendering-을 위해 있어야 하는 것입니다. "Y가 있는 경우 X 표시". 이것은 비즈니스 로직에 관한 것이 아닙니다. 이것은 당신의 모델에서 일어나야 하는 일입니다(저는 Backbone을 제안합니다. 그러면 당신은 당신의 모델에서 isXXX() 메소드가 되기 위해 당신이 원하는 무엇이든 가질 수 있습니다).

우리는 서로에게 무언가를 요구하고 있으므로 주요 변경 사항에 대한 기술적인 논의가 충분하지 않은 경우 계속하지 마십시오. 좌절하는 것은 어리석은 일입니다. 원하는 'IF'를 추가하고 완료하세요.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

@thany
주장을 반증하는 것과 그것을 기각하는 것은 차이가 있습니다. "WRONG"은 "NUH UH!"와 동일합니다.
그것에 대해 너무 개인적인 것을 시도하지 마십시오.

@tniswong
1) 그렇지 않습니다. 이것은 어떤 프레임워크에서도 마찬가지입니다.
2) 이것을 일반적인 의미로 적용한다면 Node는 그 구성요소를 모두 포함해야 합니다. 그것들이 기본적이거나 필요하다는 것은 논쟁의 여지가 있지만 표준 프레임워크 외부에서 그것들을 모두 함께 그룹화하는 것이 좋은 추상화 및 분리라는 생각으로 이어질 것입니다. 많은 프로젝트에는 그 중 어느 것도 필요하지 않으며 다른 프로젝트에는 특별한 버전이 필요합니다. 따라서 표준 세트를 플러그인하거나, 직접 작성하거나, 사용하지 않을 수 있습니다. 이러한 모든 도우미가 기본적으로 롤인되는 기술적으로 타당한 이유는 없습니다.
3) 당신의 진술은 어떤 식으로든 원래의 요점을 부정하지 않습니다. 사실, 당신은 그것을 돕습니다. If를 수정하기 위한 20개의 풀 리퀘스트. 나는 개발 팀이 그것들을 통과하는 것을 좋아할 것이라고 장담할 것이다.
4) 정확히는 '있다'입니다. 존재하는 경우 이것을 렌더링하십시오.
'아무도'에 대해 쓸 수 없을 때 하나의 반대 예를 들어야 합니다. _손을 든다_.

위의 메모에서 다음 중 하나가 필요한 것 같습니다.

1. if 을 exists 하고 핸들바를 "논리 없는" 호출을 중지합니다(그렇지 않기 때문에).
2. if 에 대한 지원을 추가하여 if 문으로 작동합니다.
3. if 완전히 제거합니다.

나는 그 옵션 중 하나에 만족할 것입니다.

잊지 마세요 {{#unless}}

2013년 11월 22일 오후 4시 40분에 Aaron M [email protected] 은 다음과 같이 썼습니다.

위의 메모에서 다음 중 하나가 필요한 것 같습니다.

존재하는 경우 이름을 바꾸고 핸들바를 "논리 없는" 호출 중지(그렇지 않기 때문에)
if 문으로 작동하도록 if 지원을 추가합니다.
완전히 제거하십시오.
나는 그 옵션 중 하나에 만족할 것입니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

이것이 진정으로 요약되는 것은 Aaron에 의해 멋지게 요약되어 있다고 생각합니다.

1. 논리가 없다고 주장하고 if/unless를 제공하여 해결해야 하는 위선이 있습니다.
2. 주어진 "if"는 잘못된 명칭입니다.

둘 다 수정하면 이 주장이 사라집니다.

2013년 11월 22일 오후 4시 43분에 Todd Niswonger [email protected]이 다음과 같이 썼습니다.

잊지 마세요 {{#unless}}

2013년 11월 22일 오후 4시 40분에 Aaron M [email protected] 은 다음과 같이 썼습니다.

위의 메모에서 다음 중 하나가 필요한 것 같습니다.

존재하는 경우 이름을 바꾸고 핸들바를 "논리 없는" 호출 중지(그렇지 않기 때문에)
if 문으로 작동하도록 if 지원을 추가합니다.
완전히 제거하십시오.
나는 그 옵션 중 하나에 만족할 것입니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

@georgefrick
나는 그의 주장이 이전에 백만 번이나 반증되었다는 이유로 단순히 그의 주장을 기각하고 있었습니다. 우리는 이 문제에 대해 너무 오랫동안 고민해 왔으며 끝내야 합니다. if 문을 추가해야 하며 아무도 불이익을 받지 않으며 모두가 행복할 것입니다. 그것을 원하지 않는 것은 모든 집에 에어컨을 원하지 않는 것과 같습니다. 내 집에서 내가 원하는 것은 내가 판단할 것이다. 그것이 당신의 것이고 당신이 그것을 원하지 않는다면 그대로 두십시오. 간단합니다.

@webgovernor
이름을 바꿀 필요가 없습니다. 적절한 if 문은 현재 문과 완전히 호환되도록 만들 수 있습니다. 현재는 "if boolean then..."이고 모든 기능을 갖춘 if-문이 정확히 그렇게 할 것입니다. 이제 해당 부울 항목만 하나의 변수가 아닌 모든 표현식이 될 수 있습니다.

@tniswong
얼마나 좋은데요? if-block이 구현될 때 너무 단순화되어 표현식을 부정할 수도 없기 때문에 더러운 추가 태그를 추가합니다. 그러나 미래의 핸들바에서는 if not 태그가 단순히 "if not"의 별칭이 될 수 있습니다. 프로그래밍에서 do..while 대 while..do와 비슷합니다. 이 둘은 주로 가독성을 위해 존재하고 기술적인 이유로 _실제로_가 아닙니다.

저도 핸들바에서 기본적인 비교를 하고 싶습니다. 나는 논리 없는 철학을 이해한다. 또한 기본 비교 지원이 더 직관적이고 사용자가 더 효율적으로 작업할 수 있도록 한다고 생각합니다. 대량의 사용자가 기본 비교 논리를 도우미로 이동하는 경우 이 철학은 사용자에게 호의를 베풀거나 인지된 차선책 동작을 단념하는 것이 아니라 더 많은 작업을 생성할 뿐입니다.

@jeremiahlee 거기에 동의하는지 동의하지 않는지 확실하지 않지만 어느 쪽이든 귀하의 의견을 읽을 수 있습니다. :)

어느 쪽이든, 나는 과거에 Handlebars로 작업했으며 적절한 if-block을 구현하도록 요청했습니다. 그 결과 논리가 모델에 남아 있어야 한다는 가짜 철학에 대한 논평이 쏟아졌습니다. 핸들바 개발자는 자신의 작은 세계에서 1밀리미터 정도 밖에 생각하고 싶어하지 않습니다(무례한 표현이 있지만 건너뛰겠습니다). 이 스레드를 증거로 삼으십시오.

이로 인해 비교를 수행하는 "언제"라는 도우미를 작성해야 했습니다. 여전히 적절한 if 블록 구성이 없지만 당시에는 충분히 가깝습니다. 그것은 나를 위해 많은 불필요한 작업을 만들었습니다.

@thany : 나는 Handlebars가 내장된 두 값에 대한 기본 비교를 가져야 한다는 데 동의합니다. 논리 없는 템플릿도 공감이 적어서는 안 됩니다.

나는 또한 @thany 와 다른 주장에 투표할 것입니다. if else 문은 너무 기본적입니다.
조건부 클래스와 select 미리 선택된와 상자 option 들 핸들의 기본 패키지 행할 수 있어야한다.

중첩 도우미를 사용하면 더 이상 문제가 되지 않습니다.

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

좋은 예 @mmun :+1:

좀 이상하고 boolean combinator가 하나도 안보이네요... 하지만 무엇보다 이 프로젝트의 메인테이너들의 전체적인 입장은 바뀌지 않고, 깨지지 않는 "NO LOGIC!!11!! 1!1" 종류의 보기입니다.