यह सहायकों द्वारा किया जा सकता है।
इसे देखें: http://kan.so/packages/details/handlebars-helpers
समान सहायक है जो दो मूल्यों की तुलना करने में सक्षम बनाता है।
आपकी आवश्यकता के लिए इसी तरह के समाधान का उपयोग किया जा सकता है।

मुझे उससे डर है।
मुझे पता है कि ऐसा कुछ हेल्पर्स के साथ किया जा सकता है ... लेकिन, मेरा मतलब है, सामान की तुलना करना इतना बुनियादी है, यह डिफ़ॉल्ट पैकेज में होना चाहिए।

अगर इसे पैकेज में शामिल किया जाता तो यह वैसे भी मददगार होता।

@ थानी http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijas बिल्कुल सही, यह वास्तव में एक सहायक होगा;) या नहीं, क्योंकि एक if-block इतना प्राथमिक है।
लिंक के लिए धन्यवाद। यह मददगार है, लेकिन मुझे एक "सहायक" लिखने में खुजली हो रही है जो मूल को अधिलेखित कर देता है, इसे _proper_ if बनाने के लिए। मुझे यकीन है कि यह संभव है। किसी भी स्वाभिमानी टेम्पलेट इंजन को उचित सशर्त स्वरूपण की आवश्यकता होती है। हैंडलबार कोई अपवाद नहीं होना चाहिए।

आपको इस तथ्य पर काबू पाने की जरूरत है कि हैंडलबार में सब कुछ जो टेम्प्लेट पर व्यावसायिक तर्क लागू करता है वह सहायक है।

प्रत्येक में निर्मित, अगर आदि को रजिस्टर हेल्पर के माध्यम से परिभाषित किया गया है। जाँच:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

तो सहायकों का उपयोग करने में कुछ भी "बुरा" नहीं है। हैंडलबार कमोबेश एक मूंछ टेम्प्लेट कंपाइलर है और उस अतिरिक्त व्यावसायिक तर्क को प्राप्त करने के लिए वे हेल्पर्स का उपयोग करते हैं। अगर आपको लगता है कि आपको रेल या कुछ और से "हेल्पर्स" शब्द के इस्तेमाल का बुरा अनुभव है।

मैंने कभी नहीं कहा कि "सहायकों" के साथ कुछ भी गलत है। यह सिर्फ इतना है कि मेरे विचार में एक उचित if-statement को विस्तार नहीं माना जाता है। एक सहायक (फिर से, मेरे विचार में) एक सीएमएस या कुछ के लिए कुछ विशिष्ट है। एक सहायक वह है जो एक विशेष ऑपरेशन या स्थिति करता है। कुछ ऐसा जो सभी के लिए नहीं है। यही है, अगर इसे कोर लाइब्रेरी के बाहर परिभाषित किया गया है। शायद jQuery-प्लगइन्स की तरह: सबसे प्राथमिक चीजें अंतर्निहित हैं, जो चीजें आपको शुरू करती हैं। लेकिन जो चीजें सभी के लिए नहीं हैं, उन्हें कोर लाइब्रेरी (यानी प्लगइन्स में) के बाहर परिभाषित किया गया है। JQuery- शब्दों में, एक साधारण फ़िल्टर-फ़ंक्शन एक प्लगइन नहीं होगा।

एक if-statement (मेरे विचार में) इस प्लगइन-प्रतिमान पर लागू नहीं होता है। यह प्राथमिक है, यह प्रोग्रामिंग और टेम्पलेट इंजन के सबसे बुनियादी सिद्धांतों में से एक है...

फिर एक त्वरित अनुवर्ती। यहाँ मुझे अब तक क्या मिला है:

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

{{#when riskfactor eq 0}}...{{/when}} जैसे मेरे टेम्पलेट में इसका उपयोग करके मुझे अपने कंसोल में [6, undefined, 0, function()] की एक सरणी मिलती है। आखिरी जो मुझे मिलता है। जब-ब्लॉक की सामग्री को संसाधित करने के लिए मुझे यही कॉल करने की आवश्यकता है। पहले तीन... ठीक है, इतना नहीं। "6" वास्तव में "जोखिम कारक" का मान है। ठीक है, मैं इसके साथ जा सकता हूँ। अपरिभाषित मुझसे परे है। मुझे लगता है कि हैंडलबार्स इनपुट ऑब्जेक्ट पर इसका मूल्यांकन करने की कोशिश कर रहा है, लेकिन यह काम नहीं करेगा। मैं उन चीजों को प्राप्त करना चाहता हूं जो वास्तव में टेम्पलेट _in_ हैं, क्योंकि इस तरह के मूल्यों का मेरी वस्तु से कोई लेना-देना नहीं है।

मैं कुछ इस तरह की उम्मीद कर रहा था ["riskfactor", "eq", "0", function()] । तभी मेरा कार्य आगे बढ़ सकता है और उसे संसाधित कर सकता है। मैं इसे "अपरिभाषित" के साथ कैसे करने जा रहा हूं?

मुझे लगता है कि हैंडलबार्स (और अन्य "लॉजिक-लेस" टेम्प्लेट) का दर्शन यह है कि टेम्प्लेट के लिए आने वाले संदर्भ को पहले से ही पूरी तरह से संसाधित किया जाना चाहिए। यदि आपके एप्लिकेशन की आंतरिक डेटा संरचनाएं टेम्पलेट के लिए उपयुक्त होने के साथ पूरी तरह से संरेखित नहीं होती हैं (जो लगभग हर बार मामला होगा), तो आपको टेम्पलेट को प्रस्तुत करने से पहले एक चरण सम्मिलित करना चाहिए जो आपके एप्लिकेशन के आंतरिक डेटा से टेम्पलेट संदर्भ बनाता है। संरचनाएं।

मेरा मानना ​​​​है कि यही इरादा है जब लोग "तर्क को प्रस्तुति से अलग करने" के बारे में बात करते हैं। एक एमवीसी सिस्टम के दृश्य घटक के रूप में हैंडलबार्स के बारे में सोचें। आपका मॉडल पहले से मौजूद है; अब आपको केवल नियंत्रक लिखना होगा (इस मामले में, यह मॉडल से देखने के लिए एक-तरफ़ा बाइंडिंग का एक सेट है)।

अपने सबसे हाल के प्रश्न का उत्तर देने के लिए, आप इसका उपयोग करना चाहते हैं:

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

हैंडलबार के भाव या तो परिवर्तनशील नाम या तार होते हैं। यदि यह एक चर नाम है, तो वर्तमान संदर्भ में देखने पर आपको चर का मान मिलेगा, नाम नहीं।

यह हैंडलबार के दायरे से बाहर है जैसा कि कुछ ने बताया है।

नहीं।
कोई भी टेम्प्लेट सिस्टम एक साधारण तुलनात्मक इफ-ब्लॉक कर सकता है, और हैंडलबार नहीं कर सकता। यह हैंडलबार्स को या तो अतिश्योक्तिपूर्ण रूप से अधूरा बनाता है, इसके निर्माता अक्षम (जो कि संभावना नहीं है), या एक सिस्टम जो एक टेम्प्लेटिंग सिस्टम के कार्यों के क्लाउड परिप्रेक्ष्य के साथ है।

तब लॉजिकलेस टेम्प्लेट इंजन का उपयोग न करें। केटीएचएक्सबाई!

समझ गया। टूडल्स।

@thany , @andriijas शायद थोड़ा कठोर था, लेकिन वह सही है। हैंडलबार का उद्देश्य तर्क-रहित होना है। आप मोटर से बाइक जरूर बना सकते हैं, लेकिन कई कंपनियां केवल मोटर-लेस बाइक बनाकर खुश हैं। इसी तरह, आप अधिक तर्क के साथ एक टेम्प्लेट सिस्टम बना सकते हैं, लेकिन ऐसा कुछ नहीं है जो हैंडलबार करने की कोशिश कर रहा है। क्षमा करें, यह वह नहीं है जिसे आप ढूंढ रहे थे।

मुझे if सहायक पर @thany का साथ

बीटीडब्लू, यदि आप मशीन के खिलाफ क्रोध करना चाहते हैं और ऐसा करना चाहते हैं, तो आप एक सहायक बना सकते हैं जो भविष्यवाणी को एक स्ट्रिंग के रूप में लेता है और फिर इसे eval (और इसे दो बार विधर्मी बना देता है: मुस्कान_इम्प :):

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-block के साथ नहीं किया जा सकता है।

मेरी राय में बैकएंड डेटा और डेटा प्रदान करने के लिए ज़िम्मेदार है, जब इस तरह के समृद्ध टेम्पलेट्स के साथ काम करते हैं। यदि बैकएंड को प्रत्येक स्थिति के लिए टेम्प्लेट-पार्सर रेडी-मेड वैरिएबल देने की आवश्यकता है, जिसके बारे में टेम्प्लेट संभवतः निर्णय ले सकता है (यहां कुछ लचीलेपन पर विचार करते हुए) तो वे केवल चर की भारी मात्रा से ही जटिल रूप से जटिल होंगे, अकेले रहने दें बैकएंड जो उन्हें बनाता है।

आप HTML को बैकएंड में भी डाल सकते हैं यदि टेम्पलेट के लिए आवश्यक प्रत्येक निर्णय के लिए बैकएंड में एक और संशोधन की आवश्यकता होती है। यह सिर्फ टेम्प्लेट के उद्देश्य का एक बड़ा हिस्सा लेता है। बैकएंड से जुड़े निर्णय पूरी तरह से अलग स्तर पर हैं। एक if-block जरूरी तर्क नहीं है। यह सिर्फ यह तय कर रहा है कि क्या/कैसे प्रस्तुत करना है।

मैं विश्वास नहीं कर सकता कि इस समस्या के लिए इतनी लंबी चर्चा की आवश्यकता है, क्या एक उचित 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 कथन से अलग नहीं है जो (इन) समानता या किसी अन्य स्थिति की जांच करता है?

केवल वास्तविक - अंतर यह है कि अन्य टेम्पलेट पुस्तकालयों के विपरीत, हैंडलबार में "तर्क-रहित" होने की आड़ में उक्त तर्क का बहुत खराब/अपूर्ण कार्यान्वयन है। मुझे खेद है, लेकिन यह पूरी तरह से बेतुका है। यदि आप तर्क को हटाना चाहते हैं तो आपको if कथन को पूरी तरह से हटा देना चाहिए। हालांकि आप ऐसा नहीं करेंगे, क्योंकि अंततः एक टेम्पलेट को उसी कारण (कारणों) के लिए if स्टेटमेंट है।

इसलिए, कथन "तर्क को प्रस्तुतिकरण से अलग करना।" गलत है, न केवल ऊपर के कारणों के लिए, क्योंकि आप टेम्पलेट से "तर्क" को नहीं हटा रहे हैं, आप इसे केवल टेम्पलेट के दूसरे भाग में ले जा रहे हैं - यानी सहायक - और शायद आपको कोड का पुन: उपयोग मिलेगा - जो एक अच्छी बात होगी - और हो सकता है कि आप नहीं करते हैं, इस मामले में आपको अन्य सहायकों के समान काम करने वाले किसी भी संख्या में सहायक मिल सकते हैं, मामूली अंतर के कारण जो सही कार्यान्वयन प्रदान करके बेहतर होता। if । यह एक अच्छा डिजाइन निर्णय कैसा है?

मैं अभी भी यह समझने के लिए संघर्ष कर रहा हूं कि क्यों, यदि कुछ "तर्क" स्वाभाविक रूप से एक विशिष्ट दृष्टिकोण से बंधे हैं और इसका कोई महत्व, महत्व और/या दृश्य के अलावा किसी अन्य चीज़ का उपयोग नहीं है, तो समस्या वास्तव में क्या है। यह बस मुझे एमवीसी अतिवाद/ओवरकिल जैसा लगता है।

@andriijas अगर मैं एक अलग टेम्पलेट लाइब्रेरी का उपयोग कर सकता हूं, तो दुर्भाग्य से निर्णय मेरे हाथ से बाहर है। टेम्पलेट लाइब्रेरी का उपयोग करने के लिए ऐसी कोई भी और सभी अनुशंसाएं जो "तर्क" की अनुमति देती हैं दुर्भाग्य से बहरे कानों पर पड़ती हैं।

क्या किसी ने वास्तव में देखा है कि वर्तमान अगर कैसे लागू किया जाता है? (वहाँ भी है जब तक कि जो अच्छा न हो)

अब जब आपने देख लिया है कि if को वर्तमान में कैसे लागू किया जाता है, तो यह आप लोगों को अधिक समझ में आ सकता है कि क्यों हैंडलबार में एक सरल और सुरुचिपूर्ण डिफ़ॉल्ट है जो अधिकांश लोगों को संतुष्ट करता है।

यहां देखें कि विस्तार करना कितना आसान है

https://github.com/elving/swag

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

स्वीकार करें कि आपके सभी ओपन सोर्स प्रोजेक्ट आपके बेकन, केवल नींव को पकाने के लिए आवश्यक सब कुछ प्रदान नहीं करते हैं।

@andriijas हाँ, unless केवल एक if है जिसका परिणाम उल्टा है। मैं नहीं देखता कि यह किसी भी चीज़ की भरपाई कैसे करता है। हेल्पर्स रेपो लिंक के लिए धन्यवाद, मैंने पहले से ही एक सहायक लिखा है, फिर भी, मुझे नहीं लगता कि यह किसी भी चीज़ के लिए क्षतिपूर्ति कैसे करता है।

हैंडलबार 10kb (मिनज़िप्ड) से थोड़ा अधिक है और स्वैग 3kb (मिनज़िप्ड) से थोड़ा कम है। तो आप अपने कोडबेस में एक 10kb टेम्प्लेट लाइब्रेरी जोड़ते हैं और आपको अपने टेम्प्लेट में तर्क जोड़ने में सक्षम होने के लिए एक और 3kb की आवश्यकता होती है। तर्क जो आप और कई अन्य कह रहे हैं कि वैसे भी आपके टेम्पलेट्स में नहीं होना चाहिए?

यह मेरे किसी भी प्रश्न का उत्तर नहीं देता है और वास्तव में यह केवल इस बात को साबित करने का काम करता है कि आपके if स्टेटमेंट ब्लॉक में अस्तित्व/झूठ के अलावा सशर्त परीक्षणों को अस्वीकार करना निरर्थक है।

@andriijas मैं देख रहा हूँ /lib/handlebars/base.js#L97 , लेकिन मुझे सच में यकीन नहीं है कि आपका क्या मतलब है। ऐसा लगता है कि इसके वैकल्पिक उपयोग का कोई रूप है, लेकिन दस्तावेज़ीकरण इसे निर्दिष्ट नहीं करता है। क्या आप समझाना चाहेंगे?

@constantology कुछ लोगों को उदाहरण के लिए इस धागे में एक और 3kb, आप और अन्य लोगों की आवश्यकता हो सकती है। बाकी 3500 जिन्होंने जीथब पर इस रेपो को तारांकित किया है, उनके शिकायत करने की संभावना नहीं है, क्योंकि उन्होंने या तो हेल्पर्स को जोड़कर या टेम्प्लेट को प्रस्तुत करने से पहले अपनी तर्क संबंधी जरूरतों को हल कर लिया है।

@piksel जो आप देख रहे हैं, वह यह है कि बिल्ट इन if किसी भी "एडऑन" के रूप में सिर्फ एक सहायक है, जिसमें कई लोगों को समस्या है, यह सोचकर कि हेल्पर्स धीमे हैं या कुछ और हैं।

आपकी परियोजना में सहायकों का उपयोग करने में कुछ भी गलत नहीं है। एक प्रोजेक्ट में मैं कुछ स्वैग हेल्पर्स का उपयोग करता हूं, जो मेरी अपनी view_helper फ़ाइल में कॉपी किया गया है, इसलिए यह 3k से भी कम है।

एक बैकबोन प्रोजेक्ट में मेरे पास मेरे विचारों पर एक getTemplateData विधि है, जहां मैं जटिल तर्क को आसान सामान के लिए उबालता हूं जो टेम्पलेट्स को क्लीनर और अनुसरण करने में आसान बनाता है, आह और साथ ही, हैंडलबार टेम्प्लेट की तुलना में यूनिट टेस्ट प्लेन जावास्क्रिप्ट के लिए आसान है।

@andriijas जो अभी भी मेरे किसी भी प्रश्न का उत्तर नहीं देता है ...

इस बिंदु पर मैं केवल वही दोहराऊंगा जो मैंने पहले ही कहा है, इसलिए यदि आपको ऐसा लगता है कि आप वास्तव में मेरे द्वारा पहले से पूछे गए किसी भी या सभी प्रश्नों का उचित उत्तर दे सकते हैं, तो मुझे यह सुनकर बहुत खुशी होगी कि आपको क्या करना है कहो। :)

पीएस रेपो को तारांकित करने वाले और/या पुस्तकालय का उपयोग करने वाले लोगों की संख्या जरूरी नहीं है कि पुस्तकालय कितना अच्छा है। संयुक्त मैक/लिनक्स की तुलना में अधिक विंडोज़ उपयोगकर्ता हैं और - इस पर निर्भर करते हुए कि आप किस ब्राउज़र आँकड़े साइट को देखते हैं - अभी भी अधिक आधुनिक ब्राउज़र की तुलना में इंटरनेट एक्सप्लोरर 6, 7 और 8 का उपयोग करने वाले अधिक लोग हैं। जो विंडोज़ को ओएसएक्स या लिनक्स से बेहतर ऑपरेटिंग सिस्टम नहीं बनाता है और यह इंटरनेट एक्सप्लोरर के पुराने संस्करणों को आधुनिक मानकों, अनुपालन ब्राउज़रों से बेहतर नहीं बनाता है।

यह पूरी चर्चा मेरे लिए असिन है। एक if सहायक है, यह तर्क है। तो पूरा तर्क-विहीन तर्क कुल स्ट्रॉ मैन है। यह ऐसा है जैसे किसी कार में खिड़कियां होती हैं जो केवल लुढ़कती हैं और लोग शिकायत करते हैं और चाहते हैं कि वे भी लुढ़कें। और निर्माता ने कहा कि वे इसे बदलने नहीं जा रहे थे क्योंकि इन कारों में यांत्रिक रूप से नियंत्रित खिड़कियां नहीं होने के सख्त दर्शन का पालन किया गया था ... या तो आप इसका समर्थन करते हैं या नहीं। एक स्ट्रॉ मैन तर्क के साथ आधे-गधे कार्यान्वयन को उचित नहीं ठहराया जाना चाहिए।

मैं पूरी तरह से सहमत हूं और समझता हूं कि टेम्प्लेट में व्यावसायिक तर्क नहीं है। लेकिन जब तक आप बेहद मामूली टेम्पलेट नहीं कर रहे हैं, तब तक आपके पास कुछ दृश्य तर्क होंगे। हैंडलबार स्पष्ट रूप से इसे पहचानते हैं क्योंकि if सहायक मौजूद है। अपने कोड में व्यू लॉजिक का एक गुच्छा जोड़कर एक हैमस्ट्रिंग if हेल्पर के आसपास काम करना जवाब नहीं है जैसा कि @thany ने बताया। मैंने इसे पहले किया है, यह तेजी से बदसूरत हो जाता है।

@mikeobrien हाँ, मैंने पहले ही पिछली टिप्पणी में इसका उल्लेख किया है। यह अनुत्तरित कई प्रश्नों में से एक था।

मैं पूरी तरह से सहमत हूं और समझता हूं कि टेम्प्लेट में व्यावसायिक तर्क नहीं है। लेकिन जब तक आप बेहद मामूली टेम्पलेट नहीं कर रहे हैं, तब तक आपके पास कुछ दृश्य तर्क होंगे।

अच्छी तरह से डाल दिया। :^)

@constantology दोह , क्षमा करें, अनुमान

मैं @constantology . से सहमत

एफडब्ल्यूआईडब्ल्यू मुझे लगता है कि हैंडलबार वास्तव में एक सुंदर और अच्छी तरह से लिखित टेम्पलेट लाइब्रेरी है।

मैं ब्लॉक और हेल्पर्स की अवधारणा को ठीक-ठाक समझता हूं, हालांकि, मुझे नहीं लगता कि कुछ छोटा करने के लिए एक हेल्पर बनाना - जिसे कोर लाइब्रेरी में सपोर्ट करके और अधिक सुरुचिपूर्ण ढंग से संभाला जा सकता है - इसका मतलब तर्क और प्रस्तुति का स्पष्ट अलगाव है। सीएसएस सशर्त बयानों के लिए समर्थन जोड़ रहा है और इसमें से कुछ पहले से ही मीडिया प्रश्नों के साथ प्राप्त किया जा सकता है, इसलिए विशुद्ध रूप से प्रस्तुतिकरण भाषा में तर्क जरूरी नहीं कि एक बड़ा बू-बू हो, अगर यह केवल "तर्क देखें" जैसा कि @mikeobrien ने इसे रखा है।

मुझे लगता है कि यह एक सीमा - if / unless ब्लॉक में सशर्त जांच की कमी - इसे सुरुचिपूर्ण और इनकैप्सुलेटेड टेम्प्लेट बनाना वास्तव में कठिन बनाता है।

साथ ही, मैं एक टेम्पलेट के माध्यम से डेटा को पार्स करने से पहले प्रीप्रोसेस करने के लिए एक विधि होने से भी सहमत हूं, हालांकि, केवल साधारण परिवर्तनों के लिए, संपूर्ण डेटा संरचना को किसी भी पुस्तकालय की इच्छा पर मोड़ने के लिए पुन: स्वरूपित करने के लिए नहीं। क्यों?

1. यदि आपको एक जटिल डेटा संरचना लेने और कुछ और सपाट बनाने की आवश्यकता है तो यह संभावित रूप से पार्सिंग के समग्र प्रदर्शन को प्रभावित कर सकता है।
2. 1 आधार पर, यह संभावित रूप से आपके व्यू कोड को अधिक भंगुर बना सकता है - और रिफैक्टर के लिए कठिन - यदि मूल स्कीमा में परिवर्तन किए जाते हैं।
3. यह दो-तरफा डेटा-बाइंडिंग को और अधिक कठिन बना सकता है क्योंकि अब आप मूल डेटा संरचना को दृश्य में मैप नहीं कर रहे हैं, जिससे कोड की मात्रा में वृद्धि करने से आपको परिवर्तनों को ट्रैक करने की आवश्यकता हो सकती है।

वे मेरे सिर के ऊपर से हैं, मैंने उसमें से किसी का समर्थन करने के लिए कोई मात्रात्मक शोध नहीं किया है, लेकिन यह विचार के लिए भोजन है। :^)

मूल प्रश्न के लिए, अगर तुलना के साथ सहायक गलत बात होगी। यह एक सामान्य परिदृश्य और सहायक है जैसे:
{{#ifzero count}}कोई परिणाम नहीं{{/ifzero}}
{{#ifsingular count}}1 परिणाम{{/ifsingular}}
{{#ifplural गणना}}{{गिनती}} परिणाम{{/ifplural}}
अधिक सहायक होगा और जो वह वास्तव में करना चाहता है उसका अनुवाद करेगा। वर्तमान यदि सिंटैक्स खाली मान प्रदर्शित करने (नहीं) के लिए उपयोगी है। एक बहुत ही सामान्य परिदृश्य भी। अगर किसी को वास्तव में एक की जरूरत है अगर तुलना के साथ यह बहुत संभावना है कि यह व्यावसायिक तर्क है और उसे इसे टेम्पलेट में नहीं करना चाहिए।

यह वास्तव में ऐसा करेगा।
हालांकि, मुझे अभी भी लगता है कि डेवलपर्स को एक निश्चित कोने में मजबूर करने के लिए यह एक इंजन पर निर्भर नहीं है, चाहे वह _in सिद्धांत_ एक अच्छा कोना हो, या नहीं। मुझे लगता है कि यह डेवलपर पर निर्भर होना चाहिए जो व्यावसायिक तर्क है, और जो टेम्पलेट तर्क है।

यही है, जब तक कि तुलना करने में सक्षम न होने की सीमा विशुद्ध रूप से एक तकनीकी सीमा है जिसने किसी तरह इसे एक प्रतिमान बना दिया है। इसका मतलब केवल इतना है कि जरूरत पड़ने पर ऐसी कार्यक्षमता को कभी नहीं जोड़ा जा सकता है। मुझे आशा है कि ऐसा नहीं हुआ है।

परीक्षण थनी। परिक्षण। आप टेम्प्लेट में तुलना नहीं करना चाहते क्योंकि आप इस तर्क का आसानी से परीक्षण नहीं कर सकते। अपने टेम्पलेट के लिए डेटा फ़ॉर्मेटर के माध्यम से सरल बूलियन मान बनाना और सेलेनियम जैसी किसी चीज़ में हुक करने और वहां परीक्षण करने की तुलना में इसका परीक्षण करना बहुत आसान है।

यह सिर्फ सिद्धांत नहीं है, यह सिर्फ 'सिद्धांत रूप में' नहीं है। टेम्प्लेट में तुलना करना, और इस तर्क का परीक्षण नहीं करना शायद वास्तविक विश्व तकनीकी ऋण बकवास होगा। इन सहायकों को न लिखें या उनका उपयोग न करें। मैंने अभी तक हैंडलबार्स के लिए हेल्पर का उपयोग नहीं किया है। हालाँकि यदि आपने किसी सहायक का उपयोग किया है, तो आप उस पर जासूसी कर सकते हैं और यह सुनिश्चित करने के लिए परीक्षण कर सकते हैं कि चीज़ चल रही है, इसलिए यह टेम्प्लेट में निर्मित तुलना से बेहतर है।

बहुत सारे तर्क मुक्त टेम्पलेट सिस्टम हैं जो तुलना की पेशकश नहीं करते हैं। उदाहरण के लिए गो जैसी जोरदार टाइप की जाने वाली भाषाओं में समानता का क्या अर्थ है? गो टेम्प्लेट में कोई तुलना नहीं है। सभी भाषाओं में मूंछें और हैंडलबार कार्यान्वयन हैं और वे समान हैं।

टेम्प्लेट से तुलना जैसे तर्क को हटाने से आपका जीवन कठिन नहीं हो जाता, यह आसान हो जाता है। तकनीकी ऋण कोई मज़ाक नहीं है, यह उत्पादों और यहां तक ​​कि कंपनियों को भी बर्बाद कर सकता है।

आ जाओ।
तुलना करना इतना कठिन नहीं है। यह रॉकेट साइंस (या ब्रेन सर्जरी) नहीं है।

बहुत ही सरल माइक्रो-टेम्पलेट्स में आपको तर्क की आवश्यकता नहीं होती है, लेकिन यदि यह और अधिक जटिल हो जाता है, तो आपको टेम्प्लेट में तर्क की आवश्यकता होगी। "व्यावसायिक तर्क" के साथ-साथ "टेम्पलेट तर्क" जैसी कोई चीज़ होती है। यह निर्धारित करना कि क्या करना है जब किसी चीज़ का केवल एक आइटम हो, या दो, या दस। पेजिंग, उदाहरण के लिए। डिवाइडर। सरल "50% से कम" और "50% से अधिक" पाठ, और मैं आगे बढ़ सकता था।

तथ्य यह है कि अन्य टेम्पलेट इंजनों में तर्क नहीं है, इसका मतलब यह नहीं है कि आपको आँख बंद करके उनका अनुसरण करना चाहिए। मेरी राय में, उनके पास भी यह गलत है।

तथ्य यह है कि, किसी बिंदु पर, आपके पास किसी प्रकार का तर्क होगा जिसकी आपको व्यावसायिक तर्क में आवश्यकता नहीं है या केवल इसलिए नहीं है, क्योंकि यह व्यावसायिक तर्क नहीं है। मैं अपने साथी डेवलपर्स के लिए एक बूलियन मूल्य रखने के लिए, हर तरह की तुलना के लिए, जो कि किसी भी वर्तमान या भविष्य के टेम्पलेट की आवश्यकता हो सकती है, की पुष्टि नहीं कर सकता।

"यह उत्पादों और यहां तक ​​कि कंपनियों को भी बर्बाद कर सकता है"? गंभीरता से?
अनुचित कार्यक्षमता भी कर सकते हैं।

इसमें क्या गलत है जो ज्यादातर लोगों को चाहिए और आप एक सहायक जोड़ रहे हैं
आपको क्या चाहिए? हर कोई जीतता है। यह इतना कठिन नहीं है, रॉकेट जैसा नहीं है
विज्ञान।

अगर यह रॉकेट साइंस है: https://github.com/elving/swag

शनिवार, मई 18, 2013 को, थानी ने लिखा:

आ जाओ।
तुलना करना इतना कठिन नहीं है। यह रॉकेट साइंस (या ब्रेन सर्जरी) नहीं है।

बहुत ही सरल माइक्रो-टेम्पलेट्स में आपको तर्क की आवश्यकता नहीं होती है, लेकिन अगर इसे कोई मिलता है
अधिक जटिल, आपको टेम्पलेट्स में तर्क की आवश्यकता होगी। एक ऐसा है
"व्यावसायिक तर्क" के साथ-साथ "टेम्पलेट तर्क" जैसी चीज़। निर्धारित करना कि क्या करना है
तब करें जब किसी चीज़ की केवल एक वस्तु हो, या दो, या दस। पेजिंग, के लिए
उदाहरण। डिवाइडर। सरल "50% से कम" और "50% से अधिक" पाठ, और मैं आगे बढ़ सकता था।

तथ्य यह है कि अन्य टेम्पलेट इंजनों में तर्क नहीं है, या तो,
इसका मतलब यह नहीं है कि आपको आँख बंद करके उनका अनुसरण करना चाहिए। उनके पास यह भी गलत है, my . में
राय।

तथ्य यह है कि, किसी बिंदु पर, आपके पास किसी प्रकार का तर्क होगा, जिसे आप सही मानते हैं
व्यावसायिक तर्क में आवश्यकता या आवश्यकता नहीं है, केवल इसलिए कि यह व्यवसाय नहीं है
तर्क। मैं अपने साथी डेवलपर्स को बूलियन मान के साथ नहीं जोड़ सकता
में, किसी भी वर्तमान या भविष्य की तुलना के हर कल्पनीय प्रकार के लिए
टेम्पलेट की कभी भी आवश्यकता हो सकती है।

"यह उत्पादों और यहां तक ​​कि कंपनियों को भी बर्बाद कर सकता है"? गंभीरता से?
अनुचित कार्यक्षमता भी कर सकते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/wycats/handlebars.js/issues/206#issuecomment -18104713
.

इसका उपयोग करने वाले अधिकांश लोग यहां वर्णित समस्या के कारण हो सकते हैं: कोई तर्क नहीं। तो निश्चित रूप से सक्रिय रूप से उपयोग करने वाले अधिकांश लोग इसके साथ कमोबेश संतुष्ट होंगे।

@thany मैं आपको महसूस करता हूं और मैं आपसे सहमत हूं।

मुझे लगता है कि हैंडलबार के पीछे के लोग इसे छोड़ना नहीं चाहते हैं, लेकिन हे, जो मैं आपको बताने जा रहा हूं वह आश्चर्यजनक खबर है:
आप परियोजना को _fork_ कर सकते हैं, पैच जोड़ सकते हैं और अपने स्वयं के कांटे का उपयोग कर सकते हैं।
गिट के जादू के कारण, केवल git pull आईएनजी द्वारा नए संस्करणों को बनाए रखना काफी आसान होना चाहिए।

और इसके लिए प्रतीक्षा करें, यह बेहतर हो जाएगा।

यदि यह एक बड़ी आवश्यकता होती है और यह समग्र रूप से बेहतर है, हो सकता है कि लोग आपके कांटे का उपयोग करना शुरू कर दें या इससे भी बेहतर, हैंडलबार के पीछे वाले लोग आपके कांटे को वापस मूल/मास्टर में मिला देंगे: नर्तक:

एक अच्छा है; डी

अगर मैं खुद को समय देता, तो निश्चित रूप से!

मैं @constantology से बिल्कुल सहमत हूं। इसके पागल में तर्क के बिना खाका है। और यदि आप चाहते थे कि तर्क-रहित टेम्पलेट हो तो आप वहां क्यों डालते हैं: "अगर" कथन जो तर्क को लाल रंग के खतरे के रूप में दर्शाता है ... समझ में नहीं आता है। मुझे लगता है कि सूप में नमक के रूप में बुनियादी तुलना तर्क की जरूरत है। @mikeobrien : "एक आधे गधे के कार्यान्वयन को एक स्ट्रॉ मैन तर्क के साथ उचित नहीं ठहराया जाना चाहिए।" :+1:

तर्कहीन टेम्पलेट्स के लिए कुछ कहा जाना है। हालांकि, मुझे लगता है कि समस्या यह है कि यहां हर कोई व्यू लॉजिक के साथ बिजनेस लॉजिक को भ्रमित कर रहा है। टेम्प्लेट में व्यावसायिक तर्क का कोई स्थान नहीं है। अवधि। हालाँकि, तर्क देखें, यह पूरी तरह से एक और मामला है। मुझे लगता है कि हैंडलबार्स को इस बात का एहसास है, यही वजह है कि उन्होंने अगर/अन्य को पहली जगह में जोड़ा, तो वे रास्ते में थोड़ा भ्रमित हो गए।

मुझे यह जानने की जरूरत है कि मेरे डेटा सरणी में एक या कई आइटम हैं, और उसके आधार पर मैं उन्हें अल्पविराम से जोड़ना चाहता हूं, या एक शब्द में बहुवचन जोड़ना चाहता हूं। करंट के साथ अगर ब्लॉक है, तो मैं ऐसा नहीं कर सकता।

यही कारण है कि मैंने यह पुल अनुरोध किया: https://github.com/wycats/handlebars.js/pull/566 और साथ में jsfiddle: http://jsfiddle.net/YsteK/

यह पुल अनुरोध एक नया सहायक प्रदान करता है: ifTest, जो जावास्क्रिप्ट अभिव्यक्ति लेता है जो जावास्क्रिप्ट की तरह मूल्यांकन करता है, संदर्भ दिया जाएगा। आनंद लेना।

ईमानदारी से यह ऐसी बुनियादी कार्यक्षमता है जिससे मुझे लगता है कि यदि आप ढांचे में तर्क नहीं बनाने की इस मानसिकता से चिपके रहना चाहते हैं (जो मुझे पूरी तरह से अतार्किक लगता है!) तो आपको तार्किक शब्दों जैसे "if" के उपयोग पर पुनर्विचार करने की आवश्यकता है। .

मैं इसे अपनी कई परियोजनाओं में जोड़ रहा हूं क्योंकि यह "0" और "1" जैसी चीजों की तुलना बूलियन अन्य मूल्यों से करते समय बहुत उपयोगी है:

Handlebars.registerHelper('ifCond', function(v1, v2, options) {
अगर (v1 === v2) {
वापसी विकल्प। एफएन (यह);
}
वापसी विकल्प। उलटा (यह);
});

मुझे लगता है कि मौजूदा "अगर" कार्यक्षमता को जिस तरह से काम करता है, उसे बनाने के लिए पूरी तरह से उचित है, लेकिन अंग्रेजी भाषा का पक्ष लें और दूसरा शब्द चुनें (या इसे वह करें जो लोग इसकी अपेक्षा करते हैं)। यह "अगर" शब्द के वास्तविक विकृति की तरह महसूस करता है, जब यह किसी अन्य संदर्भ में एक सत्य कथन की तरह व्यवहार नहीं करता है।

मैं या तो 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>

जो किसी वस्तु में उन सभी अतिरिक्त गुणों को जोड़ने के लिए थोड़े मूर्खतापूर्ण लगता है।

वेबगवर्नर - इसे देखें: http://jsfiddle.net/YsteK/

यह एक सहायक है जो इस कार्यक्षमता को सक्षम बनाता है। यह एक जावास्क्रिप्ट अभिव्यक्ति लेता है जो मूल्यांकन करता है जैसे जावास्क्रिप्ट को संदर्भ दिया जाएगा। आनंद लेना।

धन्यवाद tniswong, यह मेरे सहायक के समान ही है। मेरे पास समस्या हल हो गई है, मैं सिर्फ हैंडलबार्स "लॉजिक-लेस" हठधर्मिता के पाखंड को उजागर करना चाहता था।

कोई दिक्कत नहीं है। मैं वहीं तुम्हारे साथ हूं। मुझे हैंडलबार्स बहुत पसंद हैं, लेकिन इस हेल्पर के बिना यह काफी बेकार है।

मैंने इस सहायक को पुल-अनुरोध के रूप में प्रस्तुत किया लेकिन इसे अस्वीकार कर दिया गया। इसलिए मैंने एक और पुल-अनुरोध सबमिट किया जिसने if ब्लॉक को हटा दिया। भी खारिज कर दिया। /आहें

हाहाहा। Github को upvote बटन की जरूरत है।

इसे खारिज कर दिया गया था? -_-

हैंडलबार्स के तर्कहीन धर्म की हठ वास्तव में दिमाग को झकझोर देने वाली है।

566 और #568

उन्होंने उल्लेख किया कि वह इसे रीडमे में जोड़ सकते हैं, लेकिन मैं अपनी सांस नहीं रोक रहा हूं।

इसके लिए +1! अर्घघ!

FWIW, स्वैग रेपो हेल्पर्स प्रदान करता है जो तुलना, सॉर्टिंग और अन्य निफ्टी सामान जोड़ते हैं। मैं इसके बिना Handlebars में कुछ भी नहीं बनाता।

उस ने कहा, मैं व्यक्तिगत रूप से सहमत हूं कि हैंडलबार को यथासंभव तर्क-रहित रहने दिया जाए क्योंकि यह इसे साफ, एक्स्टेंसिबल और रखरखाव योग्य रखता है। यदि आप और अधिक चाहते हैं, तो परियोजना के दायरे से बाहर की चीजों के लिए _स्वैग_ जैसे रेपो में योगदान करें। क्या इस परियोजना के अनुरक्षकों को अपना विचार बदलना चाहिए, यह केवल एक पुल अनुरोध है: +1:

@aboutaaron यदि आप एक बयान देने जा रहे हैं, जैसे "हैंडलबार्स को जितना संभव हो

1. सबूत प्रदान करें कि हैंडलबार में कोई तर्क नहीं है। यदि आपने धागा पढ़ा है तो आप देखेंगे कि यह पहले ही सिद्ध हो चुका है कि हैंडलबार में if कथन के रूप में अधूरा तर्क होता है जो केवल "सत्यता" की जांच करता है, यदि आपने धागे के माध्यम से नहीं पढ़ा है तो मैं सुझाव देंगे कि आप ऐसा करें।
2. सबूत प्रदान करें कि हैंडलबार if कथन के रूप में अपूर्ण तर्क प्रदान करते हैं जो केवल "सत्यता" की जांच करता है, किसी भी तरह से, "इसे साफ, एक्स्टेंसिबल और रखरखाव योग्य रखता है"।
   क्या यह विरोधाभास नहीं है? यदि हैंडलबार एक्स्टेंसिबल है, तो क्या इसका मतलब यह नहीं है कि सशर्त बयानों का पूर्ण कार्यान्वयन प्रदान करना तुच्छ होगा?
   उदाहरण के लिए, एक संपूर्ण if स्टेटमेंट प्रदान करने वाले हैंडलबार्स इसे हैंडलबार और स्वैग का उपयोग करने वाले डेवलपर की तुलना में कम साफ, एक्स्टेंसिबल और रखरखाव योग्य कैसे बनाते हैं?
   कोई यह तर्क दे सकता है कि स्वैग हेल्पर्स का उपयोग करने से कोडबेस कम साफ, एक्स्टेंसिबल और रखरखाव योग्य हो जाएगा क्योंकि आपको प्रत्येक तुलना ऑपरेटर के लिए एक अलग हेल्पर का उपयोग करने की आवश्यकता होती है, अर्थात gt , gte , is , isnt , lt , lte साथ ही साथ प्रत्येक तार्किक ऑपरेटर के लिए, यानी and , or ।
   यह किसी भी अन्य भाषा में - if स्टेटमेंट के अंदर - यह सब करने की तुलना में कोड को और अधिक पठनीय कैसे बनाता है? अगर ऐसा होता तो मुझे लगता है कि प्रोग्रामिंग भाषाएं स्वयं सशर्त बयानों से दूर हो जाएंगी जो "सत्यता" के अलावा किसी और चीज की जांच करती हैं? मुझे ऐसा होता नहीं दिख रहा है।

यदि संयोग से आप "व्यावसायिक तर्क को खाके में डालने" के थके हुए - और अप्रमाणित - तर्क का उपयोग करने जा रहे हैं, तो कृपया ऐसा न करें। इसे पहले ही संबोधित किया जा चुका है - कई बार, कई लोगों द्वारा - इस धागे में। साथ ही, यदि ऐसा कुछ है जिसे आप एक वैध तर्क मानते हैं, तो यह आपके पिछले कथन के विपरीत, स्वैग लाइब्रेरी का उपयोग करने की आवश्यकता को समाप्त कर देगा।

अंत में, तथ्य यह है कि वहाँ कई पुस्तकालय हैं जो हैंडलबार्स में if के अधूरे कार्यान्वयन में पूर्णता जोड़ने की कोशिश करते हैं - एक तरह से या किसी अन्य - यह दर्शाता है कि इसकी कार्यक्षमता में इस प्रकार की कार्यक्षमता की आवश्यकता है सार। जावास्क्रिप्ट भाषा को ही देखें, हार्मनी बहुत सारी सुविधाएँ पेश कर रहा है जो तीसरे पक्ष के पुस्तकालयों, पुनरावृत्तियों, मॉड्यूल, जनरेटर, कक्षाओं, प्रॉक्सी, आदि द्वारा प्रदान की गई हैं; और डीओएम एपीआई ने तीसरे पक्ष के पुस्तकालयों, क्वेरी चयनकर्ता [सभी], सीओआरएस द्वारा प्रदान किए गए करतबों को भी लागू किया है और क्रोम कैनरी में डोम वादे का कार्यान्वयन भी है।

इस बात का कोई प्रमाण नहीं है कि "हैंडलबार को यथासंभव तर्कहीन रहने देना क्योंकि यह इसे साफ, एक्स्टेंसिबल और रखरखाव योग्य रखता है"। उसी समय, दूसरों और मैंने दिखाया है - इस धागे की पिछली टिप्पणियों में - कि थोड़ा लंबा रास्ता तय कर सकता है, अगर हैंडलबार्स को एक पूर्ण if कार्यान्वयन प्रदान करना था तो यह डेवलपर्स को बनाने के लिए एक एकीकृत एपीआई देगा उनके टेम्प्लेट पढ़ने और बनाए रखने में आसान होते हैं।

@constantology +1 आमीन।

मैं यहां {{#if some > something_else}} को आजमाकर और इस स्थिति की सच्चाई को समझने के बाद यहां पहुंचा हूं। हालांकि, मैं इस पर हैंडलबार लोगों से सहमत होने का लुत्फ उठा रहा हूं। मैंने लंबे समय तक लिक्विड का इस्तेमाल किया, और इस तरह के कमेंट थ्रेड्स अनिवार्य रूप से आधे-पके हुए फीचर्स जैसे गणित और स्ट्रिंग कॉन्सटेनेशन को जोड़ने के लिए प्रेरित करते हैं जो वास्तव में पिछले छोर से संबंधित थे।

"लॉजिक-लेस" के साथ लक्ष्य यदि कथन ऐसा प्रतीत होता है: लॉजिक पार्ट को बैक एंड पर करें, और हैंडलबार्स को "उत्तर" के साथ सिंगल वेरिएबल के रूप में प्रस्तुत करें। यदि उत्तर "हाँ" है तो ऐसा करें, अन्यथा दूसरा कार्य करें। मुझे इसमें कोई समस्या नहीं दिख रही है (उपरोक्त टिप्पणियों को पढ़कर), और अब मैं अपना कोड ठीक करने जा रहा हूं।

कुछ एम्बर अनुप्रयोगों पर काम करना और मेरी राय में फेंकना चाहता था। मुझे लगता है कि #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 के दर्शन को समझा है।
फिर, मुझे लगा कि मुझे स्वैग जैसा सहायक संग्रह चाहिए।

अब मुझे कोई दिक्कत नहीं है क्योंकि स्वैग मेरी मदद करेगा।
हालाँकि, मैं भ्रमित हो गया क्योंकि डिफ़ॉल्ट if सहायक बहुत सरल था।
यदि आप कहते हैं कि हनलेबार तर्क-रहित है, तो मुझे संदेह है कि हैंडलबार्स को अंतर्निहित सहायकों की आवश्यकता है।
अगर इसमें कोई अंतर्निहित सहायक नहीं होता, तो मुझे लगता है कि मैं हैंडलबार्स के दर्शन को और आसानी से समझ सकता हूं।

मुझे logic-less और business logic बारे में अच्छी समझ नहीं हो सकती है, मैं आपको बताना चाहता हूं कि मैंने क्या सोचा।

मेरा मानना ​​है कि यदि/जब तक (सशर्त के बिना) तर्क के रूप में आप केवल एक पर विचार नहीं कर सकते हैं, क्योंकि यह तर्क-रहित संदर्भ में है- एक बूलियन डेटा का प्रतिनिधित्व करने का एक साधन है, जैसे "{{foo}}" सिंटैक्स एक स्ट्रिंग डेटा का प्रतिनिधित्व करने का एक साधन है।

तो मुझे लगता है कि निम्नलिखित व्यवहार को रोका जाना चाहिए: "यदि यह तर्क-रहित है, तो कोई कथन क्यों है? हा-हा, चेकमेट!!!"

फिर इसे "{{#if}}" के बजाय "{{#exists}}" में बदलें क्योंकि यह अधिक समझ में आता है।

अक्टू 5, 2013, पर 10:52 AM पर, cal127 [email protected] लिखा है:

मेरा मानना ​​है कि यदि/जब तक (सशर्त के बिना) तर्क के रूप में आप केवल एक पर विचार नहीं कर सकते हैं, क्योंकि यह तर्क-रहित संदर्भ में है- एक बूलियन डेटा का प्रतिनिधित्व करने का एक साधन है, जैसे "{{foo}}" सिंटैक्स एक स्ट्रिंग डेटा का प्रतिनिधित्व करने का एक साधन है।

तो मुझे लगता है कि निम्नलिखित व्यवहार को रोका जाना चाहिए: "यदि यह तर्क-रहित है, तो कोई कथन क्यों है? हा-हा, चेकमेट!!!"

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

:अंगूठे: {{#if}} को {{#exists}} या {{#isTrue}} में बदलने के लिए

मैं सहमत हूं कि हम एक अधिक समझदार नाम ढूंढ सकते हैं। 'अस्तित्व' इसे करेगा, और मेरे सुझाव 'सत्य' या 'चालू' होंगे।

लेकिन फिर भी, ऐतिहासिक कारणों से 'अगर' नाम अभी भी अधिक उपयुक्त होगा। Handlebars' यदि कार्यान्वयन वाक्य-रचना की दृष्टि से किसी अन्य से भिन्न नहीं है यदि कार्यान्वयन है, तो यह पुराने "if ([predicate]) [do sth]" सिंटैक्स का अनुपालन करता है।

जो अलग है वह यह है कि [विधेय] एक नंगे बूल चर होना चाहिए, यह एक अभिव्यक्ति नहीं हो सकता है। लेकिन यह 'अगर' की सीमा नहीं है। हैंडलबार्स दुभाषिया के भावों के लिए समर्थन की कमी के कारण यह एक अधिक सामान्य सीमा है। (जो वास्तव में हैंडलबार्स को तर्क-रहित बीटीडब्ल्यू बनाता है, मुझे लगता है)

जिसका अर्थ है कि यह 'अगर' किसी अन्य 'अगर' से अलग नहीं है।

और 'अगर' का नाम बदलने की कोशिश कुछ लोगों द्वारा विधर्म माना जा सकता है, यह मत कहो कि मैंने आपको चेतावनी नहीं दी थी।

इसे {{#truthy}} और {{#falsey}} कहें क्योंकि यह सब {{#if}} और {{#unless}} करते हैं।

डेवलपर्स के लिए: अपने सिर को रेत से बाहर निकालें। गंभीरता से। आप देख सकते हैं कि एक उचित इफ-स्टेटमेंट की मांग है (और मैं 'मांग' शब्द का शाब्दिक रूप से उपयोग करने का इरादा रखता हूं) इसलिए तर्कहीनता के बारे में चिल्लाने के बजाय इसे लागू करें और इसे लागू करें। यदि आप चाहते हैं कि टेम्प्लेट तर्कहीन हों, तो {{#if}} और {{#each}} सहित सभी तर्कों को हटा दें।

बस एक उचित अगर-कथन लागू करें।
जो लोग अपनी तर्कहीनता में दृढ़ता से विश्वास करते हैं, वे इसका उपयोग न करने का विकल्प चुनेंगे। सरल। जैसा। उस।

मैंने आपके लिए पहले ही काम कर दिया है।

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

5 अक्टूबर 2013 को अपराह्न 3:20 बजे, थानी नोटिफिकेशन @github.com ने लिखा:

इसे {{#truthy}} और {{#falsey}} कहें क्योंकि {{#if}} और {{#unless}} यही करते हैं।

डेवलपर्स के लिए: अपने सिर को रेत से बाहर निकालें। गंभीरता से। आप देख सकते हैं कि एक उचित इफ-स्टेटमेंट की मांग है (और मैं 'मांग' शब्द का शाब्दिक रूप से उपयोग करने का इरादा रखता हूं) इसलिए तर्कहीनता के बारे में चिल्लाने के बजाय इसे लागू करें और इसे लागू करें। यदि आप चाहते हैं कि आप टेम्पलेट तर्कहीन हों, तो {{#if}} और {{#each}} सहित सभी तर्कों को हटा दें।

बस एक उचित अगर-कथन लागू करें। जो लोग अपनी तर्कहीनता में दृढ़ता से विश्वास करते हैं, वे इसका उपयोग न करने का विकल्प चुनेंगे। सरल। जैसा। उस।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

इसके लिए धन्यवाद, लेकिन समाधान कोर पैकेज में होना चाहिए। शब्द "ifTest" संभवतः केवल इसलिए है क्योंकि हैंडलबार आपके द्वारा उपयोग किए जाने से पहले "if" शब्द को हाईजैक कर लेता है।

एक और बात यह है कि आपका ifTest एक स्ट्रिंग लेता है, और रनटाइम में उस स्ट्रिंग का मूल्यांकन करता है, जबकि यदि एक उचित if-block कोर पैकेज में होगा, तो यह संकलित टेम्पलेट में हो सकता है (जो कि हैंडलबार्स के मजबूत में से एक है) अंक - एक जिसे मैं eval() का उपयोग करके अगर और अन्य के लिए ओवरबोर्ड फेंकना पसंद नहीं करता)

आप 100% सही हैं। बस उस समय मेरे पास उपलब्ध साधनों का उपयोग करना।

भले ही, यह काम करता है।

5 अक्टूबर 2013 को अपराह्न 3:41 बजे, थानी नोटिफिकेशन @github.com ने लिखा:

इसके लिए धन्यवाद, लेकिन समाधान कोर पैकेज में होना चाहिए। साथ ही, "ifTest" शब्द संभवतः केवल इसलिए है क्योंकि हैंडलबार आपके द्वारा उपयोग किए जाने से पहले "if" शब्द को हाईजैक कर लेता है। एक और बात यह है कि आपका ifTest एक स्ट्रिंग लेता है, और रनटाइम में उस स्ट्रिंग का मूल्यांकन करता है, जबकि यदि एक उचित if-block कोर पैकेज में होगा, तो यह संकलित टेम्पलेट में हो सकता है (जो कि हैंडलबार्स के मजबूत में से एक है) अंक - एक जिसे मैं इफ्स और एल्स के लिए eval () का उपयोग करके ओवरबोर्ड फेंकना पसंद नहीं करता)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

हैंडलबार्स में तुलना की खोज करते समय बस इस धागे पर ठोकर खाई। मुझे लगता है कि आपको या तो {{#if}} और {{#each}} ब्लॉक को हटा देना चाहिए / उनका नाम बदलना चाहिए, या एक उचित कथन लागू करना चाहिए। यह हर भाषा के लिए एक बुनियादी विशेषता है। अवधि। यदि आप वास्तव में तर्क-रहित टेम्पलेट चाहते हैं, तो आप इसके बजाय केवल मूंछों का उपयोग क्यों नहीं करते?

मैं समझता हूं कि डेवलपर्स के बीच एक राय है कि गैर-डेवलपर्स (यानी डिजाइनरों) द्वारा टेम्पलेट्स को पढ़ने योग्य होना चाहिए। लेकिन ए) मैंने कभी एक डिजाइनर के साथ काम नहीं किया है जहां यह एक मुद्दा था, और बी) मुझे लगता है कि एपोरैच यह होना चाहिए कि एक सामान्य समाधान अंतर्निहित उपलब्ध है, और विस्तार के रूप में आप केवल बूलियन चेक का उपयोग कर सकते हैं, इसलिए आपके पास है एक विकल्प। साथ ही, {{#ifValueEqualsA}} और {{#ifValueEqualsB}} जैसे सहायकों को जोड़ने से आपको बहुत सारे बॉयलरप्लेट कोड बनाने के लिए मजबूर होना पड़ेगा जिसकी बस जरूरत नहीं है। मैं एक बड़े मोबाइल प्रोजेक्ट में काम करता हूं और मेरे पास पहले से ही कोड की 200 लाइनें हैं जो विशिष्ट जरूरतों के लिए तुलना जोड़ती हैं। यह (उम्मीद है) हर डेवलपर्स की मानसिकता के खिलाफ जाता है कि चीजें यथासंभव सामान्य होनी चाहिए।

@ cal127 "मेरा मानना ​​​​है कि आप केवल एक ही/जब तक (बिना सशर्त) तर्क के रूप में विचार नहीं कर सकते" - तो फिर समस्या क्या है? एक बूलियन मान की जाँच करने की तुलना में एक अभिव्यक्ति की जाँच अधिक तर्क क्यों कर रही है? यह एक चेक है। अवधि। यही वह तर्क है जो यहां किया गया है, न कि अभिव्यक्ति (चूंकि एक बूलियन मान है - अनुमान लगाएं कि क्या- एक अभिव्यक्ति)। बेशक, यह मानते हुए कि अभिव्यक्ति व्यवसाय नहीं, बल्कि UI तर्क का प्रतिनिधित्व करती है।

मुझे खेद है कि तर्क-रहित टेम्पलेट इंजनों का विचार पहले से ही मरणासन्न प्रतीत होता है...मैं इसे अभी भी भविष्य में नहीं देख रहा हूँ। डेवलपर्स को ऐसे उपकरणों की आवश्यकता होती है जो चीजों को आसान और तेज बनाते हैं और अधिक जटिल नहीं होते हैं।

@ थानी चट्टानों। मैं कल मूंछ (एक और तर्क-रहित टेम्प्लेट लैंग) के बारे में आया था और यह ठीक वही सवाल था जो कुछ क्षण बाद मेरे दिमाग में आया। प्रोग्रामर ने कभी कैसे सोचा कि यह अच्छा है। यह केवल मामलों को बदतर बनाता है। प्रोग्रामिंग प्रतिमान मुझे पता है कि "प्रस्तुति तर्क से व्यावसायिक तर्क को अलग करना" है। इसका मतलब है कि प्रस्तुति में तर्क है (उदाहरण के लिए एमवीसी जैसे पैटर्न में टेम्पलेट्स शामिल/शामिल हैं)। कैसे वे इसे नकारने की कोशिश कर रहे हैं और प्रस्तुति से तर्क को हटा रहे हैं।

परिदृश्य: मैं एक दृश्य में एक लूप चला रहा हूं और मैं एक्स पुनरावृत्तियों के बाद एक क्रिया करना चाहता हूं। हैंडलबार के साथ मुझे अब एक सहायक बनाना है और फिर लूप में सही उपयोग करना है? यह मेरे जीवन को कैसे आसान बनाता है? क्या हुआ अगर गिनती==x?????? यह आपके टेम्प्लेटिंग के लिए PHP जैसी भाषा का उपयोग करने से बेहतर कैसे है? यह तार्किक टेम्पलेट इंजनों पर डिज़ाइन करने में कैसे मदद करता है?

मैं? तर्क उन्मुख नौकरी के लिए कोई तर्क-कम कुछ भी नहीं। माफ़ करना!

मैं विश्वास नहीं कर सकता कि आप कितने अज्ञानी हो सकते हैं, प्रिय विश्वासियों तर्कहीन। यह सिर्फ एक वास्तविकता नहीं है, यह एक पूरा मिथक है, एक झूठ है, एक झूठा धर्म है। कुछ पंक्तियों से अधिक कोई भी टेम्पलेट कभी भी पूरी तरह से तर्कहीन नहीं होगा। यह सिर्फ व्यावहारिक नहीं है।

अब, इस तरह के विश्वास को अपने उपयोगकर्ताओं पर लागू करना पूरी तरह से आपका निर्णय है। लेकिन तर्क की किसी भी मांग को टालना मूर्खता और अज्ञानता का प्रमाण है। विशेष रूप से इस विशेष मामले में, चूंकि पहले से ही तर्क की एक मात्रा संभव है, भले ही वह छोटा हो।

एक बार फिर, मैं दृढ़ता से आपसे पुनर्विचार करने का आग्रह करता हूं। नहीं, रुको, पुनर्विचार मत करो। बस सुनो और सही काम करो। जो लोग अपने खाके में उस मूर्खतापूर्ण तर्क को नहीं चाहते हैं, वे आगे बढ़ सकते हैं और अपने दुष्ट तरीकों को जारी रख सकते हैं और तर्क का उपयोग न करने के लिए सभी प्रकार के हुप्स के माध्यम से कूद सकते हैं।

उचित तुलना करने के लिए if-block का विस्तार करने से इसका वर्तमान उपयोग समाप्त नहीं होता है। यह उन लोगों के लिए परेशानी नहीं करेगा जिन्होंने अभी तक तार्किक प्रकाश नहीं देखा है, वे लोग वैसे ही कोड करना जारी रख सकते हैं जैसे वे थे।

यह शांत के बारे में नहीं है; आप स्वयं तर्क को तर्क के रूप में प्रस्तुति से अलग करने का उपयोग करते हैं, फिर अपने जीवन को सरल बनाने के लिए कहने के लिए इसे अनदेखा करें। आप अपने प्रोजेक्ट में कोई भी मानक हैंडलबार टेम्प्लेट लाइब्रेरी जोड़ सकते थे या अपना खुद का लिखा था।

आपने या किसी और ने इसके विरुद्ध अनेक धागों में से किसी पर भी विचार नहीं किया है। सिर्फ इसलिए कि इस सूत्र में वे तर्क स्पष्ट हैं:
1) आप एक मौजूदा पारिस्थितिकी तंत्र को बाधित कर रहे होंगे; जो उन टीमों के लिए संघर्ष और पुनर्विक्रय का कारण बनेगा जो अपडेट करना चाहते हैं लेकिन उनके पास ~ 2 वर्षों के लिए अपना स्वयं का IF है।
2) मौजूदा सहायक पुस्तकालय हैं जो आपको जरूरत पड़ने पर अन्य सभी सहायकों के साथ जोड़ देंगे, जिन्हें आप आगे मांगेंगे।
3) जैसे ही इस 'अगर' को जोड़ने की सहमति होगी, नया तर्क इसका क्रियान्वयन होगा। नाम। वाक्य - विन्यास। तर्क। आप इससे खुश होने का वादा कर सकते हैं यदि यह दिखाई देता है, लेकिन अन्य नहीं करेंगे। यहां तुरंत एक नया सूत्र होगा, यह तर्क देते हुए कि इसे किसी अन्य तरीके से काम करना चाहिए।
4) मौजूदा 'अगर' ठीक वही है जो -रेंडरिंग- के लिए होना चाहिए। "यदि Y मौजूद है तो X प्रदर्शित करें"। यह व्यावसायिक तर्क के बारे में नहीं है; जो आपके मॉडल में होना चाहिए (मैं बैकबोन का सुझाव देता हूं, तो आप जो कुछ भी चाहते हैं वह आपके मॉडल पर एक isXXX() विधि होने के लिए हो सकता है)।

चूंकि हम एक-दूसरे से चीजों के लिए पूछ रहे हैं, कृपया इसे जारी न रखें यदि आपके पास एक बड़ा बदलाव करने के लिए बहुत अच्छा तकनीकी तर्क नहीं है। निराश होना मूर्खतापूर्ण है - जो 'आईएफ' आप चाहते हैं उसे जोड़ें और किया जाए।

1) नहीं आप नहीं करेंगे। यदि आप कुछ नहीं करते हैं, तो टेम्प्लेट काम करते रहना चाहिए। बेशक सब कुछ पिछड़ा-संगत होना चाहिए। और अगर ऐसा नहीं भी है, तो बस अपग्रेड न करें।
2) एक if-statement प्राथमिक है। आप जो कह रहे हैं वह ऐसा है जैसे कार पर पहिए अब वैकल्पिक हैं।
3) if स्टेटमेंट का सिंटैक्स बहुत कम महत्व रखता है। प्रत्येक प्रोग्रामिंग भाषा में एक है, और उनमें से प्रत्येक बिल्कुल वही काम करता है। तो एक चुनें और यह ठीक रहेगा। इससे भी महत्वपूर्ण बात यह है कि हमारे पास अभी जो है, उससे कोई भी उचित if-statement होना बेहतर है।
4) गलत, "टेम्पलेट लॉजिक" के लिए ऊपर की ओर खोजें।

जहाँ तक आपके अंतिम रुख का सवाल है, तर्क _has_ बनाया गया है, और यह सही है। इस पर बार-बार तर्क दिया गया है, लेकिन यह वास्तव में एक धर्म की तरह लगता है। अटूट, और फिर भी इतना नाजुक।

जॉर्ज फ्रिक -

1) यह किसी भी अन्य ढांचे या पुस्तकालय को अपग्रेड करने से अलग कैसे है जो कभी अस्तित्व में रहा है?
2) तुम सही हो। हालाँकि, इन मूलभूत सुविधाओं को मैन्युअल रूप से जोड़ना इतना मौलिक और आवश्यक किसी चीज़ के लिए आवश्यक नहीं होना चाहिए।
3) पुल अनुरोध यही है।
4) आप पूरी तरह से बिंदु से चूक गए। इस थ्रेड पर कोई भी व्यू लेयर में व्यावसायिक तर्क के लिए बहस नहीं कर रहा है। हम दृश्य परत में उपयोगी प्रदर्शन तर्क के लिए बहस कर रहे हैं। दिया गया "अगर" सही नहीं है, तो यह किसी ऐसे व्यक्ति को भ्रमित कर देता है जिसने कभी प्रोग्रामिंग भाषा का उपयोग किया हो। यह अधिक "अस्तित्व" है।

अगर आपको लगता है कि इसे जोड़ने से लोग टेम्प्लेट में व्यावसायिक तर्क का उपयोग करेंगे, तो आप शायद सही हैं क्योंकि आप बेवकूफी को ठीक नहीं कर सकते। सिर्फ इसलिए कि कोई कुछ बुरा कर सकता है इसका मतलब यह नहीं है कि आपको इस प्रक्रिया में अन्य लोगों को कुछ अच्छा (और आवश्यक) करने से रोकना चाहिए।

22 नवंबर, 2013 को अपराह्न 3:55 बजे, जॉर्ज फ्रिक नोटिफिकेशन @github.com ने लिखा:

यह शांत के बारे में नहीं है; आप स्वयं तर्क को तर्क के रूप में प्रस्तुति से अलग करने का उपयोग करते हैं, फिर अपने जीवन को सरल बनाने के लिए कहने के लिए इसे अनदेखा करें। आप अपने प्रोजेक्ट में कोई भी मानक हैंडलबार टेम्प्लेट लाइब्रेरी जोड़ सकते थे या अपना खुद का लिखा था।

आपने या किसी और ने इसके विरुद्ध अनेक धागों में से किसी पर भी विचार नहीं किया है। बस इतना है कि इस सूत्र में तर्क स्पष्ट हैं:
1) आप एक मौजूदा पारिस्थितिकी तंत्र को बाधित कर रहे होंगे; जो उन टीमों के लिए संघर्ष और पुनर्विक्रय का कारण बनेगा जो अपडेट करना चाहते हैं लेकिन उनके पास ~ 2 वर्षों के लिए अपना स्वयं का IF है।
2) मौजूदा सहायक पुस्तकालय हैं जो आपको जरूरत पड़ने पर अन्य सभी सहायकों के साथ जोड़ देंगे, जिन्हें आप आगे मांगेंगे।
3) जैसे ही इस 'अगर' को जोड़ने की सहमति होगी, नया तर्क इसका क्रियान्वयन होगा। नाम। वाक्य - विन्यास। तर्क। आप इससे खुश होने का वादा कर सकते हैं यदि यह दिखाई देता है, लेकिन अन्य नहीं करेंगे। यहां तुरंत एक नया सूत्र होगा, यह तर्क देते हुए कि इसे किसी अन्य तरीके से काम करना चाहिए।
4) मौजूदा 'अगर' ठीक वही है जो -रेंडरिंग- के लिए होना चाहिए। "यदि Y मौजूद है तो X प्रदर्शित करें"। यह व्यावसायिक तर्क के बारे में नहीं है; जो आपके मॉडल में होना चाहिए (मैं बैकबोन का सुझाव देता हूं, तो आप जो कुछ भी चाहते हैं वह आपके मॉडल पर एक isXXX() विधि होने के लिए हो सकता है)।

चूंकि हम एक-दूसरे से चीजों के लिए पूछ रहे हैं, कृपया इसे जारी न रखें यदि आपके पास एक बड़ा बदलाव करने के लिए बहुत अच्छा तकनीकी तर्क नहीं है। निराश होना मूर्खतापूर्ण है - जो 'आईएफ' आप चाहते हैं उसे जोड़ें और किया जाए।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@ थानी
किसी तर्क का खंडन करने और उसे खारिज करने में अंतर होता है। "गलत" "एनयूएच उह!" के बराबर है।
इसके बारे में इतना व्यक्तिगत न होने का प्रयास करें।

@tniswong
1) ऐसा नहीं है, यह किसी भी ढांचे में सच है।
2) यदि आप इसे सामान्य अर्थों में लागू करते हैं, तो नोड में इसके सभी घटक शामिल होने चाहिए। यह तर्क दिया जा सकता है कि वे मौलिक हैं या आवश्यक हैं, लेकिन यह इस विचार की ओर ले जाएगा कि मानक ढांचे के बाहर उन सभी को एक साथ समूहित करना अच्छा अमूर्तता और अलगाव है। कई परियोजनाओं को उनमें से किसी की भी आवश्यकता नहीं होती है, और अन्य को विशेष संस्करणों की आवश्यकता होती है। तो आप एक मानक सेट प्लग इन कर सकते हैं, अपना खुद का लिख ​​सकते हैं, या किसी का भी उपयोग नहीं कर सकते हैं। इन सभी सहायकों को डिफ़ॉल्ट रूप से रोल करने के लिए (फिर से) कोई तकनीकी रूप से ध्वनि कारण नहीं है।
3) आपका कथन किसी भी तरह से मूल बिंदु को नकारता नहीं है, वास्तव में - आप इसकी मदद करते हैं। अगर ठीक करने के लिए 20 पुल अनुरोध। मुझे यकीन है कि देव टीम उनके माध्यम से जाना पसंद करेगी।
4) वास्तव में, यह 'अस्तित्व' है। इसे प्रस्तुत करें यदि यह मौजूद है।
जब आप 'किसी के बारे में कभी' नहीं लिख सकते हैं, तो यह एक एकल काउंटर उदाहरण लेता है। _हाथ उपर उठाता है_।

उपरोक्त नोटों से मुझे ऐसा लगता है कि निम्नलिखित में से एक आवश्यक है:

1. if से exists नाम बदलें और हैंडलबार्स को "लॉजिक-लेस" कहना बंद करें (क्योंकि यह नहीं है)
2. if कथन के रूप में व्यवहार करने के लिए if लिए समर्थन जोड़ें।
3. if पूरी तरह से हटा दें।

मुझे इनमें से किसी एक विकल्प से खुशी होगी।

मत भूलना {{#जब तक}}

22 नवंबर, 2013 को शाम 4:40 बजे, आरोन एम नोटिफिकेशन @github.com ने लिखा:

उपरोक्त नोटों से मुझे ऐसा लगता है कि निम्नलिखित में से एक आवश्यक है:

नाम बदलें यदि मौजूद है और हैंडलबार्स को "लॉजिक-लेस" कॉल करना बंद करें (क्योंकि यह नहीं है)
if कथन के रूप में व्यवहार करने के लिए समर्थन जोड़ें।
अगर पूरी तरह से हटा दें।
मुझे इनमें से किसी एक विकल्प से खुशी होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

मुझे लगता है कि यह वास्तव में क्या उबलता है हारून द्वारा अच्छी तरह से सारांशित किया गया है।

1. एक पाखंड है जिसे तर्क-रहित होने का दावा करके और अगर/जब तक की आपूर्ति करके संबोधित करने की आवश्यकता है।
2. दिया गया "if" एक मिथ्या नाम है।

उन दोनों को ठीक करो, और यह तर्क दूर हो जाता है।

22 नवंबर, 2013 को शाम 4:43 बजे टॉड निस्वोंगर [email protected] ने लिखा:

मत भूलना {{#जब तक}}

22 नवंबर, 2013 को शाम 4:40 बजे, आरोन एम नोटिफिकेशन @github.com ने लिखा:

उपरोक्त नोटों से मुझे ऐसा लगता है कि निम्नलिखित में से एक आवश्यक है:

नाम बदलें यदि मौजूद है और हैंडलबार्स को "लॉजिक-लेस" कॉल करना बंद करें (क्योंकि यह नहीं है)
if कथन के रूप में व्यवहार करने के लिए समर्थन जोड़ें।
अगर पूरी तरह से हटा दें।
मुझे इनमें से किसी एक विकल्प से खुशी होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@georgefrick
मैं उनके तर्क को केवल इसलिए खारिज कर रहा था क्योंकि इसे पहले एक लाख बार अस्वीकृत किया जा चुका है। हम इस पर बहुत लंबे समय से हैं, और इसे समाप्त होना चाहिए। if-statement जोड़ा जाना चाहिए, किसी को भी नुकसान नहीं होगा, और हर कोई खुश होगा। न चाहते हुए भी यह वैसा ही है जैसे सभी घरों में एयरकंडीशन न होना। मैं अपने घर में जो चाहता हूं उसका जज बनूंगा। अगर यह आप में है और आप इसे नहीं चाहते हैं, तो इसे रहने दें। इतना ही आसान।

@वेबगवर्नर
कोई नामकरण करने की आवश्यकता नहीं है। एक उचित if-statement को वर्तमान के साथ पूरी तरह से संगत बनाया जा सकता है। वर्तमान में यह सिर्फ "अगर बूलियन है ...", और कोई भी पूरी तरह से चित्रित अगर-कथन ठीक वैसा ही करेगा, केवल वह बूलियन चीज अब केवल एक चर के बजाय कोई अभिव्यक्ति हो सकती है।

@tniswong
उनमें से कितने अच्छे हैं, है ना? एक गंदी अतिरिक्त टैग जोड़ने के लिए क्योंकि अगर-ब्लॉक के रूप में उन्होंने इसे लागू किया है तो यह इतना अधिक सरल है कि यह एक अभिव्यक्ति को नकार भी नहीं सकता है। लेकिन भविष्य में हैंडलबार में, जब तक कि टैग केवल "यदि नहीं" के लिए उपनाम बन सकता है। किंडा जैसे करते हैं..जबकि बनाम जबकि..प्रोग्रामिंग में करते हैं, जहां दोनों मुख्य रूप से पठनीयता के लिए मौजूद हैं और किसी भी तकनीकी कारण से _really_ नहीं।

मैं भी हैंडलबार्स में बुनियादी तुलनाओं की कामना करता हूं। मैं तर्कहीन दर्शन को समझता हूं। मेरा यह भी मानना ​​है कि बुनियादी तुलना समर्थन अधिक सहज होगा और उपयोगकर्ताओं को अधिक कुशलता से काम करने की अनुमति देगा। यदि बड़े पैमाने पर उपयोगकर्ता बुनियादी तुलना तर्क को एक सहायक के पास ले जा रहे हैं, तो यह दर्शन उन्हें एक उपकार नहीं कर रहा है या एक कथित उप-व्यवहार को हतोत्साहित नहीं कर रहा है - यह सिर्फ और अधिक काम पैदा कर रहा है।

@jeremiahlee सुनिश्चित नहीं है कि आप मुझसे सहमत हैं या असहमत हैं, मैं आपकी टिप्पणी को किसी भी तरह से पढ़ सकता हूं :)

किसी भी तरह से, मैंने अतीत में हैंडलबार्स के साथ काम किया है, और मैंने उनसे उचित if-block को लागू करने का अनुरोध किया है। इसके परिणामस्वरूप एक नकली दर्शन के बारे में टिप्पणियों का एक हिमस्खलन हुआ कि तर्क मॉडल में रहना चाहिए। कोई भी हैंडलबार डेवलपर अपनी छोटी सी दुनिया के बाहर एक मिलीमीटर जितना सोचना नहीं चाहता था (इसके लिए एक अशिष्ट शब्द है, लेकिन मैं इसे छोड़ दूंगा)। इस धागे को सबूत के तौर पर देखिए।

इसने मुझे "कब" नामक एक सहायक लिखने के लिए मजबूर किया जो तुलना करता है। अभी भी कोई उचित अगर-ब्लॉक निर्माण नहीं है, लेकिन उस समय मेरे लिए काफी करीब है। हालांकि इसने मेरे लिए बहुत सारे अनावश्यक काम किए।

@ थानी : मैं मानता हूं कि हैंडलबार में निर्मित दो मूल्यों की बुनियादी तुलना होनी चाहिए। लॉजिकलेस टेम्प्लेट भी सहानुभूति-कम नहीं होने चाहिए।

मैं @thany और अन्य तर्कों के लिए भी वोट if else बयान बहुत बुनियादी हैं।
सशर्त कक्षाएं और select पूर्व-चयनित option s वाले बक्से हैंडलबार के डिफ़ॉल्ट पैकेज के साथ करने योग्य होना चाहिए।

नेस्टेड हेल्पर्स के साथ यह अब कोई समस्या नहीं है, उदाहरण के लिए

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

अच्छा उदाहरण @mmun : +1:

थोड़ा अजीब है, और मुझे कोई बूलियन कॉम्बिनेटर नहीं दिख रहा है ... लेकिन सबसे बढ़कर, यह इस परियोजना के अनुरक्षकों के समग्र दृष्टिकोण को नहीं बदलता है, जो एक अटूट "नो लॉजिक !!11 !!" लगता है। 1!1" प्रकार का दृश्य।