Mustache.js: الوصول إلى نطاق الوالدين

تم إنشاؤها على ١١ ديسمبر ٢٠١٤  ·  18تعليقات  ·  مصدر: janl/mustache.js

الوصول إلى نطاق الوالدين

مع مراعاة :

node = {
  id: 1,
  children : [
      { id : 2 },
      { id : 3 }
  ]
}

والنموذج التالي:

{{ id }} {# will output node.id #}
{{#children}}
    {{children.id}}  {# will output node.children[i].id #}
    {{id}}  {# will also output node.children[i].id #}
{{/children}}

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

السابق :

{{ id }} {# will output node.id #}
{{#children}}
    {{children.id}}  {# will output node.children[i].id #}
    {{id}}  {# will also output node.children[i].id #}
    {{ ../id }}  {# will output node.id #}
{{/children}}

لتحقيق ذلك:

  Context.prototype.lookup = function (name) {
    var cache = this.cache;

    var value;
    if (name in cache) {
      console.log(name + ' found');
      value = cache[name];
    } else {
      var context = this, names, index;

      while (context) {
        if (name.indexOf('.') > 0) {
          value = context.view;
          names = name.split('.');
          index = 0;

          while (value != null && index < names.length)
            value = value[names[index++]];
        } else if(name.match(/^\.\.\//)) {
          name = name.replace(/^\.\.\//, '');
        } else {
          value = context.view[name];
        }

        if (value != null)
          break;

        context = context.parent;
      }

      cache[name] = value;
    }

    if (isFunction(value))
      value = value.call(this.view);

    return value;
  };
Future Plugin

التعليق الأكثر فائدة

حق. لقد نسيت تماما المقاود.

دعونا نفقد المستخدمين للمقاود.
هذا قرار تصميم مقبول.

ال 18 كومينتر

هذا ليس بمواصفات mustache ، أليس كذلك؟ لا يوجد حل لهذا؟ أنا مندهش من عدم اصطدام أحد بهذا القيد من قبل.

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

من ناحية أخرى ، تحدث عن تجربة مع المقاود ؛ قد يؤدي امتلاك هذه القدرة إلى إغراء الأشخاص بإنشاء حل مجنون للنطاق الأبوي المتشابك: {{../../../id}} يصعب فهمه كثيرًا عن {{movieId}} .

صحيح أن استخدام "../" قد يؤدي إلى عدم إمكانية القراءة. ولكن من ناحية أخرى ، فإن استخدام caml لحل الوالدين لا يمكن تحقيقه حيث يمكنك الحصول على caml في النطاق المحلي. علاوة على ذلك ، فإن تحديد كلمة رئيسية للوصول إلى أحد الوالدين لن يحترم فلسفة Moustache على ما أعتقد.

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

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

ماذا عن كتابة حزمة منفصلة تقوم بتعديل الأعمال الداخلية mustache.js لإضافة الميزة المطلوبة؟ نوع من مثل البرنامج المساعد.

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

لقد كنت أفكر أكثر قليلاً في هذا ...

أعتقد أن فلسفة Moustache لا تتمثل في تمرير البيانات _ as-is_ إلى العارض ، ولكن "تحضيرها" لعرضها مسبقًا. سيكون لديك بعد ذلك خاصية parentId في عقدك.

من الأسهل أيضًا قراءة النماذج التي تحتوي على متغيرات مطولة وصيانتها:

{{ id }}
{{#children}}
    {{children.id}}
    {{id}}
{{/children}}

قبل مقابل بعد

{{ nodeId }}
{{#children}}
    {{ nodeId }}
    {{ parentId }}
{{/children}}

ذو صلة: http://stackoverflow.com/questions/4067093/mustache-read-variables-from-parent-section-in-child-section

(آسف لاستدعاء @ Bobthecow ، لكنني دائمًا أقدر حكمة

يمكنك بالفعل الصعود ، لذلك كل ما عليك فعله لإصلاح المشكلة الموضحة مع القالب الأول هو التفاف البيانات بكائن مؤقت {node: ... } ، لف القالب بـ {{#node}}...{{/node}} ثم {{node.id}} جزء يمكن أن يعمل. لست بحاجة إلى (ولن) تقوم بتحويل البيانات الموجودة بهذه الطريقة ، ويمكنك إضافة كلٍّ من "JIT" كقالب to_html() ...

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

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

IMHO ، أعتقد أن الأداة يجب أن تترك الخيار للمستخدم ، بدلاً من فرض قواعد الرأي

للقراء ، مثال على ما يقترحهrndme :

const Mustache = require('mustache')

var view = {
  node: {
    id: 5,
    children: [ { id: 6 }, { id: 7 } ]
  }
}

const template = `
{{#node}}
  children:
  {{#children}}

    id: {{ id }}
    parentId: {{ node.id }}
  {{/children}}
{{/node}}
`

const output = Mustache.render(template, view)
console.log(output)

  children:

    id: 6
    parentId: 5

    id: 7
    parentId: 5

لا يعمل استخدام القالب التالي اعتبارًا من latest ، لكن _ يجب أن يعمل_ ، imo.

const template = `
  children:
  {{#node.children}}

    id: {{ id }}
    parentId: {{ node.id }}
  {{/node.children}}
`

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

لطالما كانت فلسفة Afaik ، Moustache هي أنك تنشئ عرضًا يتم تمريره إلى القالب - فأنت لا تمرر النموذج مباشرة.

osher هل يمكنك أن تبين لنا مثالاً لا يمكنك التعامل معه بسهولة باستخدام النصيحة / الحيلة المذكورة أعلاه؟

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

خذ على سبيل المثال وثيقة اختيال ، حيث لديك مستوى الجذر ومستوى المسار ومستوى الفعل (وهناك المزيد ولكن دعنا نتوقف هنا). يمكن لكل مستوى تحديد توجيه مخصص - x-uses ، وهو توجيه DI لطبقة التنفيذ.

لنفترض أنك تريد إنشاء مستندات HTML من مستند Swagger هذا.
أنت بحاجة إلى جدول مسطح يحدد لكل معالج عملية (مستوى الفعل) DI الذي يقبله ، ومن أي طبقة يرثه.
في حين أن جميع المعلومات متأصلة في مستند Swagger - لديك الآن مشكلة.

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

ليس جيل HTML الكلاسيكي - نعم. ولكن من قال أن الشارب مخصص فقط لـ HTML؟ إنه محرك قوالب ، ويتم تنفيذ إنشاء الكود بشكل شائع باستخدام محركات القوالب هذه ؛)

لا تمرر النموذج مباشرة.

يجب أن يكون هذا اختيار المستخدم ، وليس قيدًا / قيدًا

سأعطيكم مثالاً آخر ، وسأحاول أن أفعل ذلك دون خيانة الصلصة السرية.

افترض بنية بيانات شجرة تصف الأصول التي يمتلكها لاعب في لعبة إستراتيجية.
قد تصل الشجرة إلى حوالي 5 مستويات ، على سبيل المثال:
Aliance -> Empire -> City -> Army -> Troops

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

سأضيف صعوبة: في بعض الأحيان يتم تخصيص الجيوش في فريق عمل على مستوى التحالف.
Alliance -> Rally -> Troops
يجب أن تكون الأداة عامة بدرجة كافية (تكرارية بسيطة) ولا تعتمد على مستويات محددة.

لقد قمت بحلها بما يسميه الشارب الأجزاء ، إلا أنني لم أستخدم الشارب ...

osher قال:

يجب أن يكون هذا اختيار المستخدم ، وليس قيدًا / قيدًا

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

حق. لقد نسيت تماما المقاود.

دعونا نفقد المستخدمين للمقاود.
هذا قرار تصميم مقبول.

أنا متأكد من أن osher كان ساخرًا عندما قال "هذا قرار تصميم مقبول" ، ولكن تم التخلي عن هذا الموضوع منذ عام 2016. ما الذي يحدث؟ يبدو أنه تم تجنب هذا السؤال في مستودع JavaScript هذا وكذلك في المستودع الرئيسي:
https://github.com/mustache/mustache.github.com/issues/103

أنا شخصياً أعتقد أن القدرة على الإشارة إلى النطاق الأصلي هي أقل منطقية ولا ينبغي أن تتداخل مع مُثُل الشارب.

تعجبني فكرة القدرة دائمًا على الوصول إلى النطاق الجذر برمز ، مثل "../":

Mustache.render('{{a1}}{{#a}}{{b.c}}{{../a1}}{{/a}}',{"a":{"b":{"c":"x1"}},"a1":"x2"})
"x2x1"

أود أن يعرض هذا "x2x1x2" ولكنه يحذف آخر واحد لأنه لا يعمل بهذه الطريقة.
اعتقدت أنني أوصي باستخدام شيء مثل JSONPath: https://goessner.net/articles/JsonPath/index.html#e2 ولكن بخلاف XPath لـ XML ، فإنه لا يوصي / ينفذ المشغل الرئيسي ، وهو ما كنت أتمنى ل.

ربما يمكن أن يحاول Moustache البقاء متوافقًا مع المقاود واستخدام بناء جملة ../ لسياق الوالدين؟

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

أي شيء على هذا؟

يجب أيضًا أن يكون هناك توثيق وتوصية نمطية للحالات التي يكون فيها تدوين النقاط اختياريًا.

view = { wrap: { txt: "test" } };
{{#wrap}}
  {{wrap.txt}} {{! Should I use this?}}
  {{txt}} {{! Or this?}}
{{/wrap}}

مزيد من التفاصيل هنا: https://stackoverflow.com/q/62166467/5637701

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

connor11528 picture connor11528  ·  3تعليقات

chlab picture chlab  ·  11تعليقات

barbalex picture barbalex  ·  5تعليقات

rlightner picture rlightner  ·  7تعليقات

amper5and picture amper5and  ·  5تعليقات