يمكن القيام بذلك عن طريق المساعدين.
انظر إلى هذا: http://kan.so/packages/details/handlebars-helpers
يوجد مساعد ifequal الذي يتيح مقارنة قيمتين.
يمكن استخدام حل مماثل لمتطلباتك.

كنت خائفة من ذلك.
أعرف أن شيئًا من هذا القبيل يمكن القيام به مع المساعدين ... لكن ، أعني ، مقارنة الأشياء أمر أساسي تمامًا ، يجب أن يكون في الحزمة الافتراضية.

إذا كان سيتم تضمينه في الحزمة ، فسيكون مساعدًا على أي حال.

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

andriijas صحيح تمامًا ، سيكون في الواقع مساعدًا ؛) أم لا ، لأن كتلة if أولية جدًا.
شكرا على الرابط. إنه مفيد ، لكنني أتوق لكتابة "مساعد" يقوم بالكتابة فوق الأصل إذا ، لجعله _proper_ if. أنا متأكد من أنه ممكن. يحتاج أي محرك قالب يحترم نفسه إلى تنسيق شرطي مناسب. يجب ألا تكون المقاود استثناءً.

تحتاج إلى تجاوز حقيقة أن كل شيء في المقاود يطبق منطق الأعمال على القوالب هو مساعدين.

كل ما هو مدمج في كل منها ، إذا تم تحديد الخ من خلال registerHelper. التحقق من:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

لذلك لا يوجد شيء "سيء" في استخدام المساعدين. المقاود هي أكثر أو أقل مجرد مترجم قالب شارب وللحصول على منطق الأعمال الإضافي الذي يستخدمونه. إذا كنت تعتقد أن لديك تجربة سيئة في استخدام كلمة "مساعدين" ربما من القضبان أو شيء من هذا القبيل.

لم أقل إن هناك أي خطأ في "المساعدين". الأمر مجرد أن عبارة if المناسبة لا يُفترض أن تكون امتدادًا من وجهة نظري. المساعد (مرة أخرى ، في رأيي) هو شيء خاص بنظام إدارة المحتوى أو شيء من هذا القبيل. المساعد هو الشيء الذي يؤدي عملية أو حالة خاصة. شيء لا يناسب الجميع. هذا إذا تم تعريفه خارج المكتبة الأساسية. يشبه إلى حد ما jQuery-plugins: معظم الأشياء الأساسية مدمجة ، والأشياء التي تجعلك تبدأ. لكن الأشياء التي لا تناسب الجميع يتم تحديدها خارج المكتبة الأساسية (أي في المكونات الإضافية). في مصطلحات jQuery ، لن تكون وظيفة التصفية البسيطة مكونًا إضافيًا.

لا تنطبق عبارة if (في رأيي) على نموذج البرنامج المساعد هذا. إنه أساسي ، إنه أحد المبادئ الأساسية للبرمجة ومحركات القوالب ...

ثم متابعة سريعة. هذا ما لدي حتى الآن:

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()] . عندها فقط يمكن لوظيفتي المضي قدمًا ومعالجة ذلك. كيف سأفعل ذلك بـ "غير محدد"؟

أعتقد أن فلسفة المقاود (وغيرها من القوالب "غير المنطقية" الأخرى) هي أن السياق الذي يصل إلى القالب يجب أن تتم معالجته بالكامل بالفعل. إذا كانت هياكل البيانات الداخلية للتطبيق الخاص بك لا تتوافق تمامًا مع ما سيكون مناسبًا للقالب (والذي سيكون هو الحال في كل مرة تقريبًا) ، فيجب عليك إدراج خطوة قبل تقديم القالب الذي يبني سياق القالب من البيانات الداخلية للتطبيق الخاص بك الهياكل.

أعتقد أن هذه هي النية عندما يتحدث الناس عن "فصل المنطق عن العرض." فكر في المقاود كمكون عرض لنظام MVC. النموذج الخاص بك موجود بالفعل ؛ كل ما يجب عليك كتابته الآن هو وحدة التحكم (في هذه الحالة ، تكون مجموعة من الارتباطات أحادية الاتجاه من نموذج إلى آخر).

للإجابة على أحدث سؤالك ، تريد استخدام هذا:

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

تعبيرات المقاود هي إما أسماء متغيرة أو سلاسل. إذا كان اسمًا متغيرًا ، فستحصل على قيمة المتغير عند البحث عنه في السياق الحالي ، وليس الاسم.

هذا خارج نطاق المقاود كما أشار البعض.

لا.
يمكن لأي نظام قالب القيام بكتلة مقارنة بسيطة ، ولا يستطيع المقاود ذلك. هذا يجعل المقاود إما غير مكتملة بشكل مثير للسخرية ، أو أن صانعيها غير أكفاء (وهو أمر غير مرجح) ، أو نظام به منظور غائم لمهام نظام القوالب.

لا تستخدم محرك قالب غير منطقي بعد ذلك. KTHXBAI!

فهمتك. تودلز.

thany ، ربما كان andriijas قاسيًا بعض الشيء ، لكنه على حق. تهدف المقاود إلى أن تكون خالية من المنطق. يمكنك بالتأكيد صنع دراجة بمحرك ، لكن العديد من الشركات تسعد بصنع دراجات بدون محرك فقط. وبالمثل ، يمكنك إنشاء نظام قالب بمزيد من المنطق ، ولكن هذا ليس شيئًا تحاول شركة Handlebars القيام به. آسف ليس هذا ما كنت تبحث عنه.

يجب أن أؤيدthany في if . يجب أن نكون قادرين على تمرير أي مسند إليه. عدم القدرة على تقييد فائدتها حقًا. أنا أفهم الفلسفة الكامنة وراء القوالب الخالية من المنطق ولكن التطبيق العقائدي ليس عمليًا حقًا (وبالتالي وجود المساعدين ، أليس كذلك؟). أود أن أقول إن هذا يشبه إلى حد كبير شركة الدراجات التي تضيف نسبة تروس متغيرة ، والتي ستكون معقولة تمامًا.

راجع للشغل ، إذا كنت تريد الغضب ضد الآلة والقيام بذلك ، يمكنك إنشاء مساعد يأخذ المسند كسلسلة ثم تقييمه (وجعل هذا هرطقة مرتين: 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 ، انظر إليها من منظور أفضل الممارسات ، يجب أن تخدم الواجهة الخلفية البيانات مع كل المنطق الذي تم تحديده بالفعل ، يجب أن تعرض الواجهة الأمامية (القالب) ... إذا حصلت على تمثيل JSON جيد لكائنات الواجهة الخلفية أكثر من 95 يمكن إرضاء النسبة المئوية للحالات بشروط البناء http://handlebarsjs.com/#conditionals

على محمل الجد ، ليست جميع القرارات (أو حتى 95٪) المتخذة موجهة للخلفية. على سبيل المثال ، لتحديد اسم الفئة المطلوب عرضه ، من المعقول تمامًا اتخاذ هذا القرار في القالب. شيء من هذا القبيل مرتبط بنسبة 100٪ بالواجهة الأمامية / القالب. لم تكن الواجهة الخلفية تهتم كثيرًا باسم الفئة التي يتم تقديمها. أو ماذا عن كلمات المفرد / الجمع؟ هذا شيء آخر لا يمكن فعله باستخدام if-block.

الواجهة الخلفية في رأيي هي المسؤولة عن توفير البيانات والبيانات فقط ، عند العمل مع قوالب غنية مثل هذه. إذا احتاجت الواجهة الخلفية إلى إعطاء المتغيرات الجاهزة لمحلل القوالب لكل موقف يمكن أن يتخذ القالب قرارًا بشأنه (مع الأخذ في الاعتبار بعض المرونة هنا) ، فستكون معقدة بشكل مثير للسخرية فقط من الكم الهائل من المتغيرات ، ناهيك عن الخلفية التي تجعلهم.

يمكنك أيضًا وضع 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 التي تتحقق من المساواة (in) أو أي شرط آخر؟

الاختلاف الوحيد - الحقيقي - إذن هو أنه على عكس مكتبات النماذج الأخرى ، فإن المقاود لديها تنفيذ ضعيف للغاية / غير مكتمل للمنطق المذكور تحت ستار كونها "أقل منطقية". أنا آسف ، لكن هذا كلام فارغ تمامًا. إذا كنت تريد إزالة المنطق ، فيجب عليك إزالة بيان if تمامًا. لن تفعل ذلك على الرغم من ذلك ، لأنه في النهاية يحتاج القالب إلى منطق لنفس السبب (الأسباب) التي تجعل المقاول لا يزال يحتوي على بيان if .

لذلك ، فإن عبارة "فصل المنطق عن العرض." خطأ ، ليس للأسباب المذكورة أعلاه فقط ، وأيضًا لأنك لا تزيل "المنطق" من القالب ، فأنت تقوم ببساطة بنقله إلى جزء آخر من القالب - أي المساعد - وربما تحصل على إعادة استخدام الكود - والذي سيكون شيئًا جيدًا - وربما لا تفعل ذلك ، وفي هذه الحالة قد تحصل على أي عدد من المساعدين يؤدون تقريبًا / تمامًا نفس الشيء مثل المساعدين الآخرين ، نظرًا للاختلاف الطفيف الذي كان من الممكن أن يكون أفضل من خلال توفير التنفيذ الصحيح لـ if . كيف يكون هذا قرار تصميم جيد؟

ما زلت أكافح لفهم لماذا ، إذا كان "منطق" معين مرتبطًا بطبيعته بوجهة نظر معينة وليس له أهمية و / أو أهمية و / أو استخدام لأي شيء آخر غير وجهة النظر نفسها ، فما هي المشكلة بالضبط. يبدو لي ببساطة مثل mvc التطرف / overkill.

andriijas إذا كان بإمكاني استخدام مكتبة قوالب مختلفة ،

هل نظر أي شخص بالفعل في كيفية تنفيذ التيار إذا تم تنفيذه؟ (يوجد أيضًا ما لم يكن لطيفًا)

الآن بعد أن نظرت في كيفية تنفيذ 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 قد يحتاج بعض الأشخاص إلى 3 كيلوبايت أخرى ، أنت والأشخاص الآخرون في هذا الموضوع على سبيل المثال. من غير المحتمل أن يشتكي بقية الـ 3500 الذين لعبوا دور البطولة في هذا الريبو على جيثب ، لأنهم قاموا بحل احتياجاتهم المنطقية إما عن طريق إضافة مساعدين أو القيام بذلك قبل تقديم القوالب.

piksel ما

لا حرج في استخدام المساعدين في مشروعك. في أحد المشاريع ، أستخدم بعض مساعدي swag ، الذين تم نسخهم إلى ملف view_helper الخاص بي ، لذا فهو أقل من 3 كيلوبايت.

في أحد مشاريع العمود الفقري ، لدي طريقة getTemplateData في وجهات نظري ، حيث أقوم بتلخيص المنطق المعقد لأشياء أسهل تجعل القوالب أنظف وأسهل في المتابعة ، آه وأيضًا ، من الأسهل اختبار وحدة جافا سكريبت عاديًا من قوالب المقاود.

andriijas التي لا تزال لا تجيب على أي من أسئلتي ...

في هذه المرحلة ، سأكرر ما قلته بالفعل ، لذلك إذا شعرت أنه يمكنك بالفعل تقديم إجابة معقولة لأي من الأسئلة التي طرحتها بالفعل أو جميعها ، فسأكون سعيدًا جدًا لسماع ما لديك قل. :)

ملاحظة: عدد الأشخاص الذين ميزوا الريبو و / أو يستخدمون المكتبة ليس بالضرورة مؤشرًا على مدى جودة المكتبة. يوجد عدد أكبر من مستخدمي windows أكثر من mac / linux مجتمعين - اعتمادًا على موقع إحصائيات المتصفح الذي تنظر إليه - لا يزال هناك عدد أكبر من الأشخاص الذين يستخدمون Internet Explorer 6 و 7 و 8 مجتمعين أكثر من أي متصفح حديث. هذا لا يجعل نظام التشغيل windows أفضل من نظام التشغيل osx أو linux ولا يجعل الإصدارات القديمة من Internet Explorer أفضل من المتصفحات المتوافقة مع المعايير الحديثة.

هذا النقاش برمته هو أسين بالنسبة لي. هناك مساعد if هناك ، إنه منطقي. لذا فإن الحجة الخالية من المنطق برمتها هي مجرد رجل قش. يبدو الأمر كما لو كانت السيارة بها نوافذ تتدحرج فقط ويشتكي الناس ويريدونها أيضًا. وقالت الشركة المصنعة إنها لن تغيرها لأن هذه السيارات اتبعت فلسفة صارمة بعدم وجود نوافذ يتم التحكم فيها ميكانيكيًا ... إما أن تدعمها أو لا تدعمها. لا ينبغي تبرير التنفيذ نصف المؤخر بحجة رجل قش.

أتفق تمامًا مع عدم وجود منطق عمل في القوالب وأفهمه. ولكن ما لم تكن تقوم بعمل قوالب تافهة للغاية ، فسيكون لديك بعض منطق العرض هناك. من الواضح أن المقاود تتعرف على هذا نظرًا لوجود المساعد if . إن العمل حول المساعد if المربوط عن طريق إضافة مجموعة من منطق العرض في الكود الخاص بك ليس هو الحل كما أشار thany . لقد فعلت ذلك من قبل ، إنها تصبح سريعة بشكل قبيح.

mikeobrien نعم ، لقد ذكرت ذلك بالفعل في تعليق سابق . لقد كان أحد الأسئلة العديدة التي لم تتم الإجابة عليها.

أتفق تمامًا مع عدم وجود منطق عمل في القوالب وأفهمه. ولكن ما لم تكن تقوم بعمل قوالب تافهة للغاية ، فسيكون لديك بعض منطق العرض هناك.

وضع جيد. : ^)

constantology doh ، آسف ، أعتقد أنه كان يجب أن أقرأ التعليقات السابقة بشكل أفضل. : /

أنا أتفق مع constantology

FWIW أجد أن المقاود مكتبة قوالب أنيقة حقًا ومكتوبة جيدًا.

أنا أفهم مفهوم الكتل والمساعدين جيدًا ، ومع ذلك ، لا أعتقد أن إنشاء مساعد للقيام بشيء صغير - يمكن التعامل معه بشكل أكثر أناقة من خلال دعمه في المكتبة الأساسية - يعني فصلًا واضحًا للمنطق والعرض التقديمي. تضيف CSS دعمًا للبيانات الشرطية ويمكن تحقيق بعض هذا بالفعل من خلال استعلامات الوسائط ، لذا فإن المنطق بلغة عرضية بحتة ليس بالضرورة أمرًا رائعًا ، إذا كان مجرد "عرض المنطق" كما قال

أشعر أن هذا القيد - الافتقار إلى الشيكات المشروطة في كتل if / unless - يجعل من الصعب حقًا إنشاء قوالب أنيقة ومغلفة.

أيضًا ، أوافق أيضًا على وجود طريقة للمعالجة المسبقة للبيانات قبل تحليلها من خلال قالب ، ومع ذلك ، فقط لإجراء تغييرات بسيطة ، وليس لإعادة تنسيق بنية البيانات بأكملها لتلائم إرادة أي مكتبة. لماذا ا؟

1. وهذا يمكن أن يؤثر على الأداء العام للتحليل إذا كنت بحاجة إلى اتخاذ بنية بيانات معقدة وخلق شيء أكثر مسطح.
2. استنادًا إلى 1 ، من المحتمل أن يجعل كود العرض الخاص بك أكثر هشاشة - ويصعب إعادة بنائه - إذا تم إجراء تغييرات على المخطط الأصلي.
3. يمكن أن يجعل ربط البيانات ثنائي الاتجاه أكثر صعوبة لأنك لم تعد تقوم بتعيين بنية البيانات الأصلية لطريقة العرض ، وبالتالي زيادة مقدار التعليمات البرمجية التي قد تحتاجها لتتبع التغييرات.

هذه ليست سوى أعلى رأسي ، لم أقم بأي بحث قابل للقياس لدعم أي من ذلك ، لكنه غذاء للتفكير. : ^)

بالنسبة للسؤال الأصلي ، سيكون المساعد if مع المقارنة هو الشيء الخطأ. إنه سيناريو شائع ومساعدين مثل:
{{#ifzero count}} لا نتائج {{/ ifzero}}
{{#ifsingular count}} نتيجة واحدة {{/ ifsingular}}
{{#ifplural count}} {{count}} نتائج {{/ ifplural}}
سيكون أكثر فائدة وسيترجم إلى ما يريد فعله حقًا. إذا كانت الصيغة الحالية مفيدة (وليس) لعرض القيم الفارغة. سيناريو شائع جدًا أيضًا. إذا كان شخص ما يحتاج حقًا إلى المقارنة ، فمن المحتمل جدًا أن يكون منطق الأعمال ويجب ألا يفعل ذلك في القالب.

هذا من شأنه أن يفعل ذلك بالفعل.
ومع ذلك ، ما زلت أعتقد أنه ليس من شأن المحرك أن يجبر المطورين في زاوية معينة ، سواء كان ذلك ـ من حيث المبدأ ـ ركنًا جيدًا أم لا. أعتقد أن الأمر متروك للمطور وهو منطق الأعمال ومنطق النموذج.

أي ما لم يكن الحد من عدم القدرة على إجراء مقارنات هو قيد تقني بحت جعله بطريقة ما نموذجًا. هذا يعني فقط أنه لا يمكن إضافة مثل هذه الوظيفة إذا دعت الحاجة. آمل ألا يكون هذا ما حدث.

اختبار ثاني. اختبارات. لا تريد وضع مقارنات في القوالب لأنه لا يمكنك اختبار هذا المنطق بسهولة. من الأسهل بكثير إنشاء قيم منطقية بسيطة عبر منسق بيانات للقالب الخاص بك ، واختباره ، بدلاً من ربطه بشيء مثل السيلينيوم واختباره هناك.

هذه ليست مجرد نظرية ، هذه ليست مجرد "من حيث المبدأ". ربما يكون من الهراء الفني للديون الواقعية وضع مقارنات في قوالب ، وعدم اختبار هذا المنطق. لا تكتب أو تستخدم هؤلاء المساعدين. لم أستخدم مساعدًا حتى الآن للمقاود. ومع ذلك ، إذا استخدمت مساعدًا ، فيمكنك التجسس عليه واختباره للتأكد من أن الشيء يعمل ، لذلك فهو أفضل من المقارنات المضمنة في القوالب.

هناك الكثير من أنظمة القوالب المنطقية المجانية التي لا تقدم مقارنات. على سبيل المثال في اللغات المكتوبة بشدة مثل go ، ماذا تعني المساواة؟ لا توجد مقارنات في قوالب Go. توجد عمليات تنفيذ للشارب والمقود عبر اللغات وهي نفسها.

إزالة المنطق مثل المقارنات من القوالب لا تجعل حياتك أصعب ، بل تجعلها أسهل. الديون الفنية ليست مزحة ، يمكن أن تدمر المنتجات وحتى الشركات.

هيا.
الرفقاء ليسوا بهذه الصعوبة. إنه ليس علم الصواريخ (أو جراحة الدماغ).

في القوالب الصغيرة البسيطة جدًا ، لا تحتاج إلى منطق ، ولكن إذا أصبح الأمر أكثر تعقيدًا ، فستحتاج إلى منطق في القوالب. هناك شيء مثل "منطق الأعمال" وكذلك "منطق القالب". تحديد ما يجب فعله عندما يكون هناك عنصر واحد فقط من شيء ما ، أو عنصرين ، أو عشرة. الاستدعاء ، على سبيل المثال. المقسمات. رسائل نصية بسيطة "أقل من 50٪" و "أكثر من 50٪" ، ويمكنني الاستمرار.

حقيقة أن محركات القوالب الأخرى لا تحتوي على منطق فيها ، لا تعني أيضًا أنه يجب عليك اتباعها بشكل أعمى. إنهم يخطئون أيضًا في رأيي.

الحقيقة ، في مرحلة ما ، سيكون لديك نوع من المنطق الذي لا تحتاجه أو تريده في منطق العمل ، ببساطة لأنه ليس منطق الأعمال. لا يمكنني التحدث مع زملائي المطورين الذين يحتاجون إلى قيمة منطقية ، لكل نوع قابل للتحقيق من المقارنة قد يحتاجه أي نموذج حالي أو مستقبلي.

"يمكن أن تدمر المنتجات وحتى الشركات"؟ عنجد؟
يمكن أن تؤدي الوظائف غير الملائمة أيضًا.

ما الخطأ في شحن ما يحتاجه معظم الأشخاص وأنت تضيف مساعدًا
على ماذا تحتاج؟ الجميع يفوز. ليس بهذه الصعوبة ، ليس مثل الصاروخ
علم.

إذا كان علم الصواريخ: https://github.com/elving/swag

في يوم السبت ، 18 مايو 2013 ، كتب thany:

هيا.
الرفقاء ليسوا بهذه الصعوبة. إنه ليس علم الصواريخ (أو جراحة الدماغ).

في القوالب الصغيرة البسيطة جدًا ، لا تحتاج إلى منطق ، ولكن إذا حصل على أي منطق
أكثر تعقيدًا ، ستحتاج إلى منطق في القوالب. هناك مثل هذا
الشيء مثل "منطق الأعمال" وكذلك "منطق القالب". تحديد ماذا
تفعل عندما يكون هناك عنصر واحد فقط من شيء ما ، أو عنصرين ، أو عشرة. الاستدعاء لـ
مثال. المقسمات. رسائل نصية بسيطة "أقل من 50٪" و "أكثر من 50٪" ، ويمكنني الاستمرار.

حقيقة أن محركات القوالب الأخرى ليس لديها منطق فيها ،
لا يعني أنه يجب عليك اتباعهم بشكل أعمى. لديهم خطأ أيضا في بلدي
رأي.

الحقيقة ، في مرحلة ما ، سيكون لديك نوع من المنطق الذي لديك للتو
لا تحتاج أو تريد في منطق الأعمال ، ببساطة لأنه ليس عملًا
منطق. لا يمكنني التحدث مع زملائي المطورين الذين يحتاجون إلى قيمة منطقية
في ، لكل نوع من المقارنة يمكن استخلاصه من أي مقارنة حالية أو مستقبلية
يمكن أن يحتاجها النموذج في أي وقت.

"يمكن أن تدمر المنتجات وحتى الشركات"؟ عنجد؟
يمكن أن تؤدي الوظائف غير الملائمة أيضًا.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/wycats/handlebars.js/issues/206#issuecomment -18104713
.

قد يكون معظم الناس _ لا _ يستخدمونه بسبب المشكلة الموضحة هنا: لا منطق. لذلك بالطبع سيكون معظم الأشخاص الذين يستخدمونها بنشاط أكثر أو أقل محتوى معها.

thany أشعر بك وأنا أتفق معك.

أعتقد أن الأشخاص الذين يقفون وراء المقاود لا يريدون التخلي عن هذا ، لكن ما سأخبركم به هو أخبار رائعة:
يمكنك _fork _ المشروع وإضافة الباتش واستخدام الشوكة الخاصة بك.
نظرًا لسحر git ، فمن السهل جدًا مواكبة الإصدارات الجديدة من خلال git pull ing.

وانتظرها ، تتحسن.

إذا كانت هذه حاجة كبيرة وكانت أفضل بشكل عام ، فربما يبدأ الناس في استخدام الشوكة الخاصة بك أو حتى أفضل من ذلك ، فإن الرجال الذين يقفون وراء المقاود سوف يدمجون الشوكة في الأصل / السيد: الراقص:

لديك فكرة جيدة ؛ د

إذا كنت سأمنح نفسي الوقت ، بالتأكيد!

أتفق تمامًا معconstantology. إنه مجنون به قالب بدون منطق. وإذا أردت أن يكون لديك نموذج بدون منطق ، فلماذا وضعت هناك عبارة "if" ، فما الذي يمثل المنطق على أنه خطر باللون الأحمر ... لا يُنشئ. أعتقد أن منطق المقارنة الأساسي مطلوب مثل الملح في الحساء. mikeobrien : "لا ينبغي تبرير تطبيق نصف الحمار بحجة رجل قش." : +1:

هناك شيء يمكن قوله للقوالب غير المنطقية. رغم ذلك ، أشعر أن المشكلة هي أن الجميع هنا يخلط بين منطق الأعمال ومنطق العرض. منطق الأعمال ليس له مكان في القوالب. فترة. عرض المنطق ، مع ذلك ، هو مسألة أخرى تماما. أعتقد أن المقاود تدرك هذا ولهذا السبب أضافوا if / else في المقام الأول ، فقد أصبحوا مرتبكين قليلاً على طول الطريق.

أحتاج إلى معرفة ما إذا كانت مصفوفة البيانات الخاصة بي تحتوي على عنصر واحد أو عدة عناصر ، وبناءً على ذلك أريد ضمهم بفاصلات ، أو إضافة صيغة الجمع إلى كلمة. مع كتلة if الحالية ، لا يمكنني القيام بذلك.

لهذا السبب قدمت طلب السحب هذا: https://github.com/wycats/handlebars.js/pull/566 والمرفق jsfiddle: http://jsfiddle.net/YsteK/

يوفر طلب السحب هذا مساعدًا جديدًا: ifTest ، والذي يأخذ تعبير جافا سكريبت الذي يقيّم تمامًا مثل جافا سكريبت الذي يعطي السياق. يتمتع.

بصراحة ، هذه وظيفة أساسية تجعلني أشعر أنه إذا كنت تريد التمسك بعقلية عدم وجود منطق مدمج في إطار العمل (والذي يبدو غير منطقي تمامًا بالنسبة لي!) فأنت بحاجة إلى إعادة النظر في استخدام المصطلحات المنطقية مثل "إذا" .

أجد نفسي أضيف هذا إلى الكثير من مشاريعي لمجرد أنه مفيد جدًا عند مقارنة أشياء مثل "0" و "1" بقيم منطقية أخرى:

Handlebars.registerHelper ('ifCond' ، الوظيفة (v1 ، v2 ، الخيارات) {
إذا (v1 === v2) {
خيارات العودة. fn (هذا) ؛
}
عودة options.inverse (هذا) ؛
}) ؛

أعتقد أنه من العدل تمامًا جعل وظيفة "if" الحالية تعمل بالطريقة التي تعمل بها ، ولكن اجعل اللغة الإنجليزية معروفًا واختر كلمة أخرى (أو اجعلها تفعل ما يتوقعه الناس). يبدو الأمر وكأنه تحريف حقيقي لمصطلح "if" عندما لا يتصرف ببساطة مثل عبارة if true في أي سياق آخر.

أرغب في إضافة تصويت آخر إما لإزالة 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 ، هذا مشابه جدًا لمساعدتي. لقد تم حل المشكلة ، أردت فقط تسليط الضوء على نفاق عقيدة "عقيدة المنطق".

لا مشكلة. أنا هناك معك. أنا أحب المقاود ، لكنها عديمة الفائدة بدون هذا المساعد.

لقد قدمت هذا المساعد كطلب سحب ولكن تم رفضه. لذلك قدمت طلب سحب آخر أدى إلى إزالة كتلة if. كما رفضت. /تنهد

ها ها ها ها. يحتاج Github إلى زر التصويت.

تم رفضه؟ -_-

إن عناد الدين غير المنطقي للمقاود هو حقًا محير للعقل.

566 و 568

لقد ذكر أنه قد يضيفه إلى برنامج README ، لكنني لا أحبس أنفاسي.

+1 لهذا! أرغه!

FWIW ، يوفر Swag repo مساعدين يضيفون المقارنة والفرز وأشياء أخرى رائعة. لا أقوم ببناء أي شيء في المقاود بدونها.

ومع ذلك ، أنا شخصياً أتفق مع السماح للمقاود بالبقاء دون منطق قدر الإمكان لأنه يحافظ عليها نظيفة وقابلة للتوسيع وقابلة للصيانة. إذا كنت تريد المزيد ، فساهم في إعادة شراء مثل _Swag_ لأشياء خارج نطاق المشروع. إذا غير القائمين على هذا المشروع رأيهم ، فكل ما يتطلبه الأمر هو طلب سحب: +1:

aboutaaron إذا كنت تريد الإدلاء ببيان مثل ، "السماح للمقاود بالبقاء دون منطق قدر الإمكان لأنه يحافظ على نظافتها وقابليتها للصيانة" ، فيجب على الأقل أن تتمتع باللياقة من أجل:

1. تقديم دليل على أن المقاود لا تحتوي على منطق. إذا كنت قد قرأت الخيط ، فسترى أنه قد تم بالفعل إثبات أن المقاود تحتوي على منطق غير كامل في شكل عبارة if تتحقق فقط من "الصدق" ، إذا لم تكن قد قرأت من خلال الخيط ، فأنا نقترح عليك القيام بذلك.
2. تقديم دليل على أن المقاود تقدم منطقًا غير مكتمل في شكل عبارة if التي تتحقق فقط من "الصدق" ، بطريقة ما ، "تحافظ عليها نظيفة وقابلة للتوسيع وقابلة للصيانة".
   أليس هذا تناقضا؟ إذا كانت المقاود قابلة للتوسعة ، ألا يعني ذلك أنه سيكون من التافه توفير تنفيذ كامل للعبارات الشرطية؟
   كيف ، على سبيل المثال ، أن المقاود التي توفر بيانًا كاملاً if تجعله أقل نظافة ، وقابلية للتوسيع ، وقابلية للصيانة من مطور يستخدم المقاود وغنيمة ؟
   يمكن للمرء أن يجادل في أن استخدام مساعدي swag سيجعل قاعدة الشفرة أقل نظافة وقابلية للتوسيع وقابلية للصيانة لأنك تحتاج إلى استخدام مساعد مختلف لكل عامل مقارنة ، على سبيل المثال ، gt ، gte ، is ، isnt ، lt ، lte بالإضافة إلى كل عامل تشغيل منطقي ، على سبيل المثال and ، or .
   كيف يجعل هذا الكود أكثر قابلية للقراءة من القيام بكل هذا بنفس الطريقة التي يقوم بها المرء - داخل بيان if - بأي لغة أخرى؟ إذا كان هذا هو الحال ، فسأفترض أن لغات البرمجة نفسها ستتخلص من العبارات الشرطية التي تتحقق من أي شيء آخر غير "الصدق"؟ لا أرى هذا يحدث.

إذا كنت ستستخدم بالصدفة الحجة المتعبة - وغير المثبتة - "لوضع منطق الأعمال في القالب" ، من فضلك لا تفعل ذلك. تمت معالجة هذا بالفعل - عدة مرات ، من قبل عدة أشخاص - في هذا الموضوع. في الوقت نفسه ، إذا كان هذا شيئًا تعتبره حجة صحيحة ، فإن ذلك من شأنه أن يلغي الحاجة إلى استخدام مكتبة swag ، بما يتعارض مع

في الختام ، فإن حقيقة وجود العديد من المكتبات التي تسعى إلى إضافة الكمال إلى التنفيذ غير المكتمل لـ if في المقاود - بطريقة أو بأخرى - يدل على أن هناك حاجة لهذا النوع من الوظائف في جوهر. انظر إلى لغة JavaScript نفسها ، تقدم Harmony الكثير من الميزات التي تم توفيرها بواسطة مكتبات الطرف الثالث ، والمكررات ، والوحدات النمطية ، والمولدات ، والفئات ، والوكلاء ، وما إلى ذلك ؛ ونفذت واجهة برمجة تطبيقات DOM و DOM أيضًا ميزات تم توفيرها بواسطة مكتبات الجهات الخارجية ، ومحدد الاستعلام [الكل] ، و CORS وهناك أيضًا تنفيذ لـ DOM Promises في chrome canary.

لا يوجد دليل على أن "ترك المقاود تبقى دون منطق قدر الإمكان لأنها تحافظ عليها نظيفة وقابلة للتوسيع وقابلة للصيانة". في الوقت نفسه ، لقد أوضحت أنا والآخرون - في التعليقات السابقة لهذا الموضوع - أن القليل يمكن أن يقطع شوطًا طويلاً ، إذا كانت المقاود ستوفر تنفيذًا كاملاً لـ if ، فستمنح المطورين واجهة برمجة تطبيقات موحدة للقيام بها قوالبها أسهل في القراءة والصيانة.

@ كونستانتولوجيا +1 آمين.

لقد وصلت للتو إلى هنا بعد تجربة {{#if something> something_else}} وإدراك حقيقة هذا الموقف. ومع ذلك ، فإنني أميل إلى الاتفاق مع المقاود على هذا. لقد استخدمت السائل لفترة طويلة ، وتؤدي تعليقات مثل هذه حتمًا إلى إضافة ميزات نصف مخبوزة مثل الرياضيات وسلسلة السلسلة التي تنتمي بالفعل إلى النهاية الخلفية.

الهدف مع عبارة "logic-less" إذا كان يبدو أنه: قم بتنفيذ الجزء المنطقي في النهاية الخلفية ، وقم بتقديم المقاود مع "الإجابة" كمتغير واحد. إذا كانت الإجابة "نعم" ، فافعل ذلك ، وإلا افعل الشيء الآخر. لا أرى مشكلة في ذلك (بعد قراءة التعليقات أعلاه) ، وسأقوم بإصلاح الكود الخاص بي الآن.

أعمل على بعض تطبيقات 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 أقل منطقية ، فأنا أشك في أن المقود يحتاج إلى مساعدين مدمجين.
إذا لم يكن لديه مساعدين مدمجين ، أعتقد أنه يمكنني فهم فلسفة المقاود بسهولة أكبر.

قد لا يكون لدي فهم جيد حول logic-less و business logic ، أريد أن أخبرك بما كنت أفكر فيه.

أعتقد أنه لا يمكنك ببساطة اعتبار if / إلا (بدون شروط) منطقًا ، حيث إنه - في السياق غير المنطقي - وسيلة لتمثيل البيانات المنطقية ، مثل "{{foo}}" بناء الجملة هو وسيلة لتمثيل سلسلة البيانات.

لذلك أعتقد أنه يجب إيقاف السلوك التالي: "إذا كان الأمر أقل منطقية ، فلماذا توجد عبارة if؟ HA-HA ، checkmate !!!"

ثم قم بتغييرها إلى "{{#exists}}" بدلاً من "{{#if}}" لأن ذلك أكثر منطقية.

في 5 تشرين الأول (أكتوبر) 2013 ، الساعة 10:52 صباحًا ، كتب cal127 [email protected] :

أعتقد أنه لا يمكنك ببساطة اعتبار if / إلا (بدون شروط) منطقًا ، حيث إنه - في السياق غير المنطقي - وسيلة لتمثيل البيانات المنطقية ، مثل "{{foo}}" بناء الجملة هو وسيلة لتمثيل سلسلة البيانات.

لذلك أعتقد أنه يجب إيقاف السلوك التالي: "إذا كان الأمر أقل منطقية ، فلماذا توجد عبارة if؟ HA-HA ، checkmate !!!"

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

: thumbsup: لتغيير {{#if}} إلى {{#exists}} أو {{#isTrue}}

أوافق على أنه يمكننا العثور على اسم أكثر منطقية. "موجود" من شأنه أن يفعل ذلك ، وستكون اقتراحاتي "صحيحة" أو "تشغيل".

لكن مع ذلك ، فإن الاسم "إذا" سيكون أكثر ملاءمة لأسباب تاريخية. إذا كان التنفيذ لا يختلف من الناحية التركيبية عن أي تطبيق آخر ، فإنه يتوافق مع بناء الجملة القديم "if ([predicate]) [do sth]".

الأمر المختلف هو أن [المسند] يجب أن يكون متغيرًا منطقيًا مكشوفًا ، ولا يمكن أن يكون تعبيرًا. لكن هذا ليس تحديد "إذا". هذا قيد أكثر عمومية ناتج عن نقص الدعم لتعبيرات مترجم المقاود. (وهو بالضبط ما يجعل المقودات أقل منطقية ، على ما أعتقد)

مما يعني أن هذا "if" لا يختلف عن أي "if" آخر.

ومحاولة تغيير اسم "إذا" قد يعتبرها البعض بدعة ، لا تقل إنني لم أحذرك.

أطلق عليها {{#truthy}} و {{#falsey}} لأن هذا هو كل ما يفعله {{#if}} و {{#unless}} .

للمطورين: أخرجوا رؤوسكم من الرمال. عنجد. يمكنك أن ترى أن هناك طلبًا على عبارة if المناسبة (وأنا أنوي استخدام كلمة "طلب" حرفيًا تمامًا) لذا اذهب ونفذها ، بدلاً من التذمر من اللامبالاة. إذا كنت تريد أن تكون القوالب غير منطقية ، فتخلص من كل منطق ، بما في ذلك {{#if}} و {{#each}} .

فقط قم بتنفيذ عبارة if-statement المناسبة.
الأشخاص الذين يؤمنون بشدة بغير منطقهم ، سيختارون عدم استخدامه. بسيط. كما. الذي - التي.

حتى أنني قمت بالفعل بالعمل نيابة عنك.

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

في 5 تشرين الأول (أكتوبر) 2013 ، الساعة 3:20 مساءً ، كتب thany [email protected] :

أطلق عليها اسم {{#truthy}} و {{#falsey}} لأن هذا هو كل ما يفعله {{#if}} و {{#unless}}.

للمطورين: أخرجوا رؤوسكم من الرمال. عنجد. يمكنك أن ترى أن هناك طلبًا على عبارة if المناسبة (وأنا أنوي استخدام كلمة "طلب" حرفيًا تمامًا) لذا اذهب ونفذها ، بدلاً من التذمر من اللامبالاة. إذا كنت تريد أن تكون النماذج خالية من المنطق ، فتخلص من كل المنطق ، بما في ذلك {{#if}} و {{#each}}.

فقط قم بتنفيذ عبارة if-statement المناسبة. الأشخاص الذين يؤمنون بشدة بغير منطقهم ، سيختارون عدم استخدامه. بسيط. كما. الذي - التي.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

شكرًا على ذلك ، ولكن الحل يجب أن يكون في الحزمة الأساسية. يُفترض أن المصطلح "ifTest" هو فقط لأن المقاود تختطف المصطلح "إذا" قبل أن تتمكن من استخدامه.

شيء آخر هو أن ifTest الخاص بك يأخذ سلسلة ، ويقوم بتقييم تلك السلسلة في وقت التشغيل ، بينما إذا كانت كتلة if المناسبة في الحزمة الأساسية ، فيمكن أن تكون في القالب المترجم (وهو بالضبط أحد أقوى المقابض نقاط - نقطة لا أحب التخلص منها باستخدام eval() لـ ifs و elses)

أنت على صواب 100٪. فقط باستخدام الأدوات المتاحة لي في ذلك الوقت.

بغض النظر ، إنه يعمل.

في 5 تشرين الأول (أكتوبر) 2013 ، الساعة 3:41 مساءً ، كتب thany [email protected] :

شكرًا على ذلك ، ولكن الحل يجب أن يكون في الحزمة الأساسية. أيضًا ، يُفترض أن المصطلح "ifTest" هو فقط لأن المقاود تختطف المصطلح "إذا" قبل أن تتمكن من استخدامه. شيء آخر هو أن ifTest الخاص بك يأخذ سلسلة ، ويقوم بتقييم تلك السلسلة في وقت التشغيل ، بينما إذا كانت كتلة if المناسبة في الحزمة الأساسية ، فيمكن أن تكون في القالب المترجم (وهو بالضبط أحد أقوى المقابض نقاط - نقطة لا أحب طرحها في البحر باستخدام EVAL () لـ ifs و elses)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

عثرت للتو على هذا الخيط أثناء البحث عن المقارنة في المقاود. أعتقد أنه يجب عليك إما إزالة / إعادة تسمية كتل {{#if}} و {{#each}} ، أو تنفيذ عبارة if المناسبة. إنها ميزة أساسية لكل لغة. فترة. إذا كنت تريد حقًا قوالب بلا منطق ، فلماذا لا تستخدم Moustache بدلاً من ذلك؟

أفهم أن هناك رأيًا بين المطورين بأن القوالب يجب أن تكون قابلة للقراءة من قبل غير المطورين (أي المصممين). لكن أ) لم أعمل مطلقًا مع مصمم حيث كانت هذه مشكلة ، و ب) أعتقد أنه يجب أن يكون الحل هو أن الحل العام متاح مدمج ، وكامتداد يمكنك استخدام الاختيار المنطقي فقط ، لذلك لديك خيار. بالإضافة إلى ذلك ، فإن إضافة مساعدين مثل {{#ifValueEqualsA}} و {{#ifValueEqualsB}} ستجبرك على إنشاء الكثير من التعليمات البرمجية المعيارية التي لا تحتاج إليها ببساطة. أنا أعمل في مشروع محمول ليس بهذا الحجم ولدي بالفعل 200 سطر من التعليمات البرمجية التي تضيف فقط مقارنات لاحتياجات معينة. هذا يتعارض (نأمل) كل مطور عقلي أن الأشياء يجب أن تكون عامة قدر الإمكان.

@ cal127 "أعتقد أنه لا يمكنك اعتبار إذا / ما لم (بدون شروط)

أنا آسف لأن فكرة المحركات التي لا تعتمد على المنطق تبدو محتضرة بالفعل ... لا أرى أن هذا لا يزال مستمراً في المستقبل. يحتاج المطورون إلى أدوات تجعل الأمور أسهل وأسرع وليس أكثر تعقيدًا.

تضمين التغريدة جئت بالأمس عن الشارب (نموذج آخر بدون منطق) وكان هذا هو السؤال الذي ظهر في رأسي بعد لحظات قليلة. كيف اعتقد المبرمجون أن هذا رائع. هذا فقط يجعل الأمور أسوأ. إن نموذج البرمجة الذي أعرفه هو "فصل منطق الأعمال عن منطق العرض التقديمي". يعني هذا def وجود منطق في العرض التقديمي (العروض التي تحتوي على / تتضمن قوالب بنمط مثل mvc على سبيل المثال). كيف يحاولون نفي ذلك وإزالة المنطق من العرض.

السيناريو: أقوم بتشغيل حلقة في طريقة عرض وأريد تنفيذ إجراء بعد تكرار x. مع المقاود ، يجب أن أذهب الآن لإنشاء مساعد ثم استخدمه في الحلقة ، أليس كذلك؟ كيف يجعل هذا حياتي أسهل؟ ماذا يحدث إذا كان العد == x ؟؟؟؟؟ كيف يكون ذلك أفضل من استخدام لغة مثل php نفسها لقوالبك؟ كيف يساعد التصميم على محركات القوالب المنطقية؟

أنا؟ لا منطق ولا أي شيء لوظيفة المنحى المنطقي. آسف!

لا أصدق كيف يمكن أن تكون جاهلاً ، أيها المؤمنون بلا منطق. إنها ليست حقيقة ، إنها أسطورة كاملة ، مغالطة ، ديانة زائفة. لن يكون أي قالب أكثر من بضعة أسطر عديمة المنطق تمامًا. إنه ببساطة غير عملي.

الآن ، إن فرض مثل هذا الاعتقاد على المستخدمين هو قرارك تمامًا. لكن الاستمرار في تجاهل أي طلب للمنطق هو دليل على الغباء والجهل. خاصة في هذه الحالة بالذات ، نظرًا لوجود قدر ممكن من المنطق ، وإن كان ضئيلًا.

مرة أخرى ، أحثك ​​بشدة على إعادة النظر. لا ، انتظر ، لا تعيد النظر. فقط استمع وافعل الشيء الصحيح. يمكن للأشخاص الذين لا يريدون أيًا من هذا المنطق السخيف في قوالبهم المضي قدمًا ومواصلة طرقهم الشريرة والقفز عبر جميع أنواع الحلقات حتى لا يستخدموا المنطق.

لا يؤدي توسيع كتلة if لإجراء مقارنات مناسبة إلى استبعاد استخدامها الحالي. لن يتسبب ذلك في مشكلة بالنسبة لأولئك الذين لم يروا بعد الضوء المنطقي ، فقد يستمر هؤلاء الأشخاص في البرمجة كما كانوا.

لا يتعلق الأمر بالروعة ؛ أنت نفسك تستخدم فصل المنطق عن العرض كحجة ثم تتجاهلها لتطلب تبسيط حياتك. يمكنك إضافة أي من مكتبات قوالب المقاود القياسية إلى مشروعك أو كتابتها بنفسك.

لقد تناولت أنت أو أي شخص آخر أيًا من الحجج العديدة ضد هذا في أي من الخيوط العديدة. فقط لكي تكون تلك الحجج واضحة في هذا الموضوع:
1) ستقوم بتعطيل نظام بيئي قائم ؛ مما سيؤدي إلى حدوث تعارضات وإعادة صياغة للفرق التي ترغب في التحديث ولكن لديها IF الخاصة بها لمدة عامين تقريبًا.
2) توجد مكتبات مساعدة حالية ستضيف إذا كنت بحاجة ، إلى جانب جميع المساعدين الآخرين الذين ستطلبهم بعد ذلك.
3) بمجرد الموافقة على إضافة هذا "إذا" ، ستكون الحجة الجديدة هي تنفيذ ذلك. اسم. بناء الجملة. الحجج. قد تعد بأن تكون سعيدًا إذا ظهر ذلك ، لكن الآخرين لن يفعلوا ذلك. سيكون هناك على الفور موضوع (خيوط) جديدة هنا يجادل بأنه يجب أن يعمل بطريقة أخرى.
4) "إذا" الموجود هو بالضبط ما يجب أن يكون موجودًا للعرض. "عرض X في حالة وجود Y". لا يتعلق الأمر بمنطق الأعمال. والتي يجب أن تحدث في نموذجك (أقترح العمود الفقري ، ثم يمكنك الحصول على ما تريده إذا كنت تريد أن تكون مجرد طريقة isXXX () على نموذجك).

نظرًا لأننا نطلب بعضنا من بعض الأشياء ، من فضلك لا تواصل هذا إذا لم يكن لديك حجة تقنية جيدة لإجراء تغيير كبير. الشعور بالإحباط أمر سخيف - أضف "إذا كنت تريد" وانتهى الأمر.

1) لا لن تفعل. إذا لم تفعل أي شيء ، فيجب أن تظل القوالب تعمل. بالطبع يجب أن يكون كل شيء متوافقًا مع الإصدارات السابقة. وحتى لو لم يكن الأمر كذلك ، فلا تقم بالترقية.
2) بيان الشرط أساسي. ما تقوله مثل العجلات في السيارة أصبح الآن اختياريًا.
3) بناء جملة عبارة if قليلة الأهمية. كل لغة برمجة لديها لغة واحدة ، وكل منها تفعل الشيء نفسه بالضبط. لذا اختر واحدة وستكون جيدة. والأهم من ذلك ، أن وجود أي عبارة if-statement مناسبة أفضل مما لدينا الآن.
4) خطأ ، ابحث عن "منطق النموذج".

أما موقفك الأخير ، فقد أثيرت الحجة ، وهي صحيحة. لقد تم الجدل حوله مرارًا وتكرارًا ، لكنه يبدو حقًا كدين. غير قابل للكسر ، لكنه هش للغاية.

جورج فريك -

1) كيف يختلف هذا عن ترقية أي إطار عمل أو مكتبة أخرى موجودة على الإطلاق؟
2) أنت على حق. رغم ذلك ، فإن إضافة هذه الميزات الأساسية يدويًا لا ينبغي أن تكون ضرورية لشيء أساسي وضروري للغاية.
3) هذا هو الغرض من طلبات السحب.
4) لقد فاتتك النقطة تمامًا. لا أحد في هذا الموضوع يدافع عن منطق الأعمال في طبقة العرض. نحن ندافع عن منطق العرض المفيد في طبقة العرض. إن "if" المعطى ليس صحيحًا ، مما يجعله مربكًا لأي شخص استخدم لغة برمجة على الإطلاق. إنه أكثر من "موجود".

إذا كنت تعتقد أن إضافة هذا قد يتسبب في استخدام الأشخاص لمنطق الأعمال في القوالب ، فمن المحتمل أنك محق لأنك لا تستطيع إصلاح مشكلة الغباء. فقط لأن شخصًا ما يمكنه فعل شيء سيئ لا يعني أنه يجب عليك منع الآخرين من فعل شيء جيد (وضروري) في هذه العملية.

في 22 تشرين الثاني (نوفمبر) 2013 ، الساعة 3:55 مساءً ، كتب George Frick [email protected] :

لا يتعلق الأمر بالروعة ؛ أنت نفسك تستخدم فصل المنطق عن العرض كحجة ثم تتجاهلها لتطلب تبسيط حياتك. يمكنك إضافة أي من مكتبات قوالب المقاود القياسية إلى مشروعك أو كتابتها بنفسك.

لقد تناولت أنت أو أي شخص آخر أيًا من الحجج العديدة ضد هذا في أي من الخيوط العديدة. فقط بحيث تكون الحجج واضحة في هذا الموضوع:
1) ستقوم بتعطيل نظام بيئي قائم ؛ مما سيؤدي إلى حدوث تعارضات وإعادة صياغة للفرق التي ترغب في التحديث ولكن لديها IF الخاصة بها لمدة عامين تقريبًا.
2) توجد مكتبات مساعدة حالية ستضيف إذا كنت بحاجة ، إلى جانب جميع المساعدين الآخرين الذين ستطلبهم بعد ذلك.
3) بمجرد الموافقة على إضافة هذا "إذا" ، ستكون الحجة الجديدة هي تنفيذ ذلك. اسم. بناء الجملة. الحجج. قد تعد بأن تكون سعيدًا إذا ظهر ذلك ، لكن الآخرين لن يفعلوا ذلك. سيكون هناك على الفور موضوع (خيوط) جديدة هنا يجادل بأنه يجب أن يعمل بطريقة أخرى.
4) "إذا" الموجود هو بالضبط ما يجب أن يكون موجودًا للعرض. "عرض X في حالة وجود Y". لا يتعلق الأمر بمنطق الأعمال. والتي يجب أن تحدث في نموذجك (أقترح العمود الفقري ، ثم يمكنك الحصول على ما تريده إذا كنت تريد أن تكون مجرد طريقة isXXX () على نموذجك).

نظرًا لأننا نطلب بعضنا من بعض الأشياء ، من فضلك لا تواصل هذا إذا لم يكن لديك حجة تقنية جيدة لإجراء تغيير كبير. الشعور بالإحباط أمر سخيف - أضف "إذا كنت تريد" وانتهى الأمر.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

thany
هناك فرق بين دحض الحجة ورفضها. كلمة "WRONG" تعني "NUH UH!".
حاول ألا تكون شخصيًا جدًا حيال ذلك أيضًا.

تضمين التغريدة
1) الأمر ليس كذلك ، هذا ينطبق أيضًا على أي إطار عمل.
2) إذا قمت بتطبيق هذا بشكل عام ، فيجب أن تتضمن Node جميع مكوناتها. يمكن المجادلة بأنها أساسية أو ضرورية ولكنها ستؤدي إلى فكرة أن تجميعها جميعًا معًا خارج إطار العمل القياسي هو تجريد جيد وفصل. العديد من المشاريع لا تحتاج إلى أي منها ، والبعض الآخر يحتاج إلى إصدارات خاصة. لذا يمكنك إضافة مجموعة قياسية أو كتابة مجموعتك الخاصة أو عدم استخدام أي منها. لا يوجد (مرة أخرى) أي سبب سليم تقنيًا لجميع هؤلاء المساعدين بشكل افتراضي.
3) بيانك لا ينفي بأي شكل من الأشكال النقطة الأصلية ، في الواقع - أنت تساعده. 20 طلب سحب لإصلاح إذا. أراهن أن فريق التطوير سيحب المرور بها.
4) بالضبط ، إنه "موجود". جعل هذا إذا كان موجودًا.
عندما لا تستطيع الكتابة عن "أي شخص على الإطلاق" ، فإن ذلك يأخذ مثالًا مضادًا واحدًا. _يرفع يده_.

من الملاحظات المذكورة أعلاه يبدو لي أن أحد الأمور التالية ضروري:

1. أعد تسمية if إلى exists وتوقف عن استدعاء المقاود "logic-less" (لأنه ليس كذلك)
2. أضف دعمًا لـ if لتتصرف ككشف حساب if .
3. إزالة if بالكامل.

سأكون سعيدًا بأي من هذه الخيارات.

لا تنسى {{#unless}}

في 22 تشرين الثاني (نوفمبر) 2013 ، في تمام الساعة 4:40 مساءً ، كتب Aaron M [email protected] :

من الملاحظات المذكورة أعلاه يبدو لي أن أحد الأمور التالية ضروري:

إعادة تسمية إذا كان موجودًا وتوقف عن استدعاء المقاود "logic-less" (لأنه ليس كذلك)
أضف دعمًا لما إذا كان يتصرف على أنه عبارة "if".
أزلها تمامًا.
سأكون سعيدًا بأي من هذه الخيارات.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

أعتقد أن ما يتلخص فيه هذا حقًا قد لخصه آرون بشكل رائع.

1. هناك نفاق يجب معالجته من خلال الادعاء بأنه أقل من المنطق وتوفير شرط إذا / ما لم.
2. المعطى "إذا" هو تسمية خاطئة.

أصلح كلاهما ، وستختفي هذه الحجة.

في 22 تشرين الثاني (نوفمبر) 2013 ، الساعة 4:43 مساءً ، كتب تود نيسونغر [email protected] :

لا تنسى {{#unless}}

في 22 تشرين الثاني (نوفمبر) 2013 ، في تمام الساعة 4:40 مساءً ، كتب Aaron M [email protected] :

من الملاحظات المذكورة أعلاه يبدو لي أن أحد الأمور التالية ضروري:

إعادة تسمية إذا كان موجودًا وتوقف عن استدعاء المقاود "logic-less" (لأنه ليس كذلك)
أضف دعمًا لما إذا كان يتصرف على أنه عبارة "if".
أزلها تمامًا.
سأكون سعيدًا بأي من هذه الخيارات.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

تضمين التغريدة
كنت أرفض حجته لمجرد أنه تم دحضها مليون مرة من قبل. لقد انتهينا من هذا الأمر لفترة طويلة جدًا ، ويجب أن ينتهي. يجب إضافة عبارة if ، ولن يكون هناك أي شخص محروم ، وسيكون الجميع سعداء. عدم الرغبة في ذلك هو نفس عدم الرغبة في مكيفات الهواء في جميع المنازل. سأكون الحكم على ما أريد في بيتي. إذا كان في ملكك ولا تريده ، فاتركه كذلك. سهل هكذا.

تضمين التغريدة
لا يلزم القيام بإعادة تسمية. يمكن جعل عبارة if المناسبة متوافقة تمامًا مع العبارة الحالية. حاليًا هو فقط "if boolean then ..." ، وأي عبارة if كاملة الميزات ستفعل ذلك تمامًا ، فقط هذا الشيء المنطقي يمكن الآن أن يكون أي تعبير بدلاً من متغير واحد فقط.

تضمين التغريدة
كم هو لطيف منهم ، أليس كذلك؟ لإضافة علامة إضافية قذرة لأن if-block أثناء تنفيذها يتم تبسيطها بشكل مفرط بحيث لا يمكنها حتى إبطال أي تعبير. ولكن في المقاود المستقبلية ، قد تصبح علامة "ما لم" ببساطة اسمًا مستعارًا لـ "إن لم يكن". Kinda like do.. while vs while .. do في البرمجة ، حيث يوجد الاثنان أساسًا لسهولة القراءة وليس _حقيقة_ لأي سبب تقني.

أنا أيضًا أرغب في إجراء مقارنات أساسية في المقاود. أنا أفهم فلسفة اللا منطق. أعتقد أيضًا أن دعم المقارنة الأساسي سيكون أكثر ملاءمة ويسمح للمستخدمين بالعمل بكفاءة أكبر. إذا كان المستخدمون بشكل جماعي ينقلون منطق المقارنة الأساسي إلى مساعد ، فإن هذه الفلسفة لا تقدم لهم خدمة أو تثني سلوكًا دون المستوى الأمثل - إنها فقط تخلق المزيد من العمل.

jeremiahlee لست متأكدًا مما إذا كنت توافق أو لا توافق معي هناك ، يمكنني قراءة تعليقك في كلتا الحالتين :)

في كلتا الحالتين ، لقد عملت مع المقاود في الماضي ، وقد طلبت منهم تنفيذ كتلة if-block مناسبة. أدى ذلك إلى سيل من التعليقات حول فلسفة زائفة مفادها أن المنطق يجب أن يظل في النموذج. لم يرغب أي من مطوري المقاود في التفكير بقدر ملليمتر خارج عالمهم الصغير (هناك كلمة وقحة لذلك ، لكنني سأتخطى ذلك). مجرد إلقاء نظرة على هذا الموضوع كدليل.

أجبرني هذا على كتابة مساعد يسمى "متى" يقوم بإجراء المقارنات. لا يوجد حتى الآن بناء مناسب ، ولكنه قريب بما يكفي بالنسبة لي في ذلك الوقت. لقد خلق الكثير من العمل غير الضروري بالنسبة لي.

thany : أوافق على أن المقاود يجب أن تحتوي على مقارنة أساسية بين قيمتين مدمجتين. يجب ألا تكون القوالب غير المنطقية أيضًا أقل تعاطفًا.

سأصوت أيضًا لصالح thany والحجج الأخرى. بيانات if else بسيطة للغاية.
يجب أن تكون الفئات الشرطية ومربعات select مع option s محددة مسبقًا قابلة للتنفيذ مع الحزمة الافتراضية من المقاود.

مع المساعدين المتداخلين ، لم تعد هذه مشكلة ، على سبيل المثال

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

مثال جيد mmun : +1:

غريب بعض الشيء ، ولا أرى أي تركيبات منطقية ... ولكن الأهم من ذلك كله ، أنه لا يغير وجهة النظر العامة للقائمين على صيانة هذا المشروع ، والذي يبدو أنه غير قابل للكسر "بلا منطق !! 11 !! 1! 1 "نوع من العرض.