Mustache.js: विकल्प जोड़ें: अज्ञात चर पर चेतावनी

को निर्मित 14 सित॰ 2016 · 18टिप्पणियाँ · स्रोत: janl/mustache.js

कभी-कभी हम परिवर्तनीय नामों पर टाइपो बनाते हैं (यहां तक कि स्वत: सुझाव के साथ भी)।
यह बहुत अच्छा होगा यदि कोई कॉन्फ़िगरेशन था तो मूंछ-जेएस एक खाली स्ट्रिंग वापस देने के बजाय 'अज्ञात' चर पर एक चेतावनी उत्पन्न करेगा (हालांकि यह कल्पना-अनुरूप है)।

मूंछें मैन-पेज कहता है:
By default a variable "miss" returns an empty string. This can usually be configured in your Mustache library. The Ruby version of Mustache supports raising an exception in this situation, for instance.

स्रोत

MatthijsZw

👍12 👀1 🚀1 ❤1 🎉1

सबसे उपयोगी टिप्पणी

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

मेरे पास https://github.com/ScottFreeCode/mustache.js पर एक कार्यशील प्रोटोटाइप है, हालांकि मैं इसके लिए एक परीक्षण लिखने का तरीका जानने में कुछ मदद का उपयोग कर सकता हूं।

ScottFreeCode 23 सित॰ 2016

👍4

सभी 18 टिप्पणियाँ

स्थानीय रूप से विकसित करते समय इस सुविधा को अन्य ढांचे से प्यार करें, इसलिए मुझसे +1 करें! मुझे लगता है कि यह महत्वपूर्ण है कि प्रदर्शन पर इसका कोई प्रभाव नहीं पड़ता है। शायद कोर को वैसे ही रखते हुए भी करने योग्य? उदाहरण के लिए विकास के दौरान इस तरह के व्यवहार को सक्षम करने के लिए कुछ आंतरिक तरीकों को ओवरराइड करके।

phillipj 19 सित॰ 2016

शायद एक mustache.dev.js जो mustache.js का उपयोग करके बनाया गया है और फ़ंक्शन चेकिंग तर्क वाले ओवरराइड करता है?

Romanx 20 सित॰ 2016

ScottFreeCode 23 सित॰ 2016

👍4

हम्म, तो किसी वस्तु के अस्तित्व को if ( {{#thing}} ) के रूप में उपयोग करने से कोई त्रुटि होगी? (मुझे लगता है कि यह काफी सामान्य है)

या केवल चरों का वास्तविक प्रतिपादन ( {{ id }} ) त्रुटि उत्पन्न करेगा? आप क्या सोच रहे थे?

संपादित करें: बहुत अच्छी सुविधा है कि मैं डिफ़ॉल्ट रूप से एक प्रमुख में सक्षम करने के लिए +1 करूंगा यदि यह परेशानी का अंत नहीं करता है।

dasilvacontin 8 नव॰ 2016

मेरे दिमाग में पहली त्रुटि होनी चाहिए, दूसरी 'चेतावनी'।
दोनों के लिए मैं जानना चाहता हूं कि एक लापता मूल्य है।

हालांकि दूसरे मामले में यह तकनीकी रूप से टूट नहीं सकता है, यह पृष्ठ पर बहुत बड़ा प्रभाव डाल सकता है।

इसके अलावा, दूसरा तरीका अच्छा होगा: अप्रयुक्त चर ... लेकिन यह बहुत अधिक प्रभाव डालता है, मुझे लगता है! :डी

8 नवंबर 2016 को 14:19 बजे डेविड डा सिल्वा नोटिफिकेशन @github.com ने लिखा:
हम्म, तो किसी वस्तु के अस्तित्व का उपयोग if ({{#thing}}) के रूप में करने से कोई त्रुटि होगी? (मुझे लगता है कि यह काफी सामान्य है)
या केवल चरों का वास्तविक प्रतिपादन ({{ id }}) त्रुटि उत्पन्न करेगा? आप क्या सोच रहे थे?
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://github.com/janl/mustache.js/issues/599#issuecomment -259133973, या थ्रेड को म्यूट करें https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lके।

MatthijsZw 8 नव॰ 2016

मेरे दिमाग में पहली त्रुटि होनी चाहिए, दूसरी 'चेतावनी'।
दोनों के लिए मैं जानना चाहता हूं कि एक लापता मूल्य है।

@MatthijsZw मैं देखता हूँ। मुझे बस याद आया कि आप संपत्ति के लिए null मूल्य स्टोर कर सकते हैं, जो कि करना अच्छी बात होगी, और इसलिए कोई अपवाद नहीं होगा। (विशेष रूप से if मामले के लिए इसका उल्लेख करते हुए)

संपादित करें: मेरी वर्तमान स्थिति यह है कि मैं दोनों पर एरर करना पसंद करूंगा। मैं लगातार व्यवहार पसंद करता हूं, और आप null को खाली-लापता मूल्यों के लिए लागू करेंगे, जो मुझे लगता है कि बेहतर है।

इसके अलावा, दूसरा तरीका अच्छा होगा: अप्रयुक्त चर ... लेकिन यह बहुत अधिक प्रभाव डालता है, मुझे लगता है! :डी

मैं सोच रहा हूं कि किसी टेम्पलेट की अपेक्षा वाले डेटा के लिए स्कीमा प्राप्त करना अच्छा होगा, और ग्राफ़क्यूएल क्वेरी उत्पन्न करने के लिए इसका उपयोग करें ... या कुछ इसी तरह।

dasilvacontin 8 नव॰ 2016

आगे के प्रतिबिंब पर, मुझे लगता है कि यहां समस्या का एक हिस्सा यह है कि लापता डेटा अमान्य है _क्योंकि_ - और इसलिए _only if_ - टेम्पलेट _expecting_ वह डेटा है। इसलिए, लापता डेटा कि टेम्पलेट सिर्फ सादा प्रदर्शन होगा, उस तर्क से हमेशा अमान्य होता है, लेकिन यह कल्पना की जा सकती है कि एक टेम्पलेट एक स्थान पर एक निश्चित डेटा उपलब्ध होने की उम्मीद कर सकता है और उस पर किसी प्रकार का सही/गलत ध्वज (इसलिए यह है अमान्य अगर यह इतना झूठा नहीं है जितना कि लापता है और इसलिए उस अपेक्षा को पूरा नहीं कर रहा है), लेकिन दूसरे में यह उम्मीद कर सकता है कि डेटा उपलब्ध हो सकता है या नहीं और इस पर शाखा हो सकती है (जिस स्थिति में यह कभी भी अमान्य नहीं है)।

उस परिप्रेक्ष्य में, इसे नियंत्रित करने के लिए null का उपयोग करना वास्तव में मेरे लिए बहुत मायने नहीं रखता है:

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

टेम्प्लेट की ओर से विभिन्न अपेक्षाओं के लिए हमें दो प्रकार की शाखाओं की आवश्यकता होती है। मेरे ज्ञान के लिए कौन सा दुर्भाग्यपूर्ण है क्योंकि भाषा-अज्ञेय मूंछ विनिर्देश, जबकि यह अनुमति देता है (लेकिन अनिवार्य नहीं) कॉन्फ़िगरेशन की अनुपलब्ध डेटा एक त्रुटि है, जहां तक मुझे पता है कि एक अलग प्रकार की शाखा के लिए कुछ भी नहीं है कि इस बिंदु पर भिन्न होगा। हम्म...

फ्लिपसाइड पर, मैं वर्तमान में सोच रहा हूं कि बाहरी/अधिशेष/अप्रयुक्त डेटा वास्तव में डेटा के अमान्य होने का मामला नहीं है, यह टेम्पलेट के अमान्य होने की बात है यदि यह उस डेटा का उपयोग नहीं करता है जब एप्लिकेशन/डेटा/ मॉडल को उम्मीद है कि इसका इस्तेमाल किया जाएगा। यही है, यदि कुछ सामान संभावित रूप से उपयोग करने योग्य है, लेकिन टेम्पलेट यह तय कर सकता है कि क्या यह प्रासंगिक है, तो इससे कोई फर्क नहीं पड़ता कि टेम्पलेट उस सामान को प्रिंट करता है, लेकिन अगर कुछ सामान वास्तव में उपयोगकर्ता को प्रदर्शित करने के लिए _needs_ है, तो यदि टेम्पलेट ' इसे प्रदर्शित न करें यह एक त्रुटि है। एक प्रकार के उलटफेर के रूप में, उम्मीद टेम्पलेट के बाहर है (मॉडल में?) और उस उम्मीद को पूरा करने में विफल होने की अमान्यता टेम्पलेट में निहित है। शायद अलग से निपटने के लिए सबसे अच्छा, मुझे लगता है।

उपरोक्त हैं, मुझे लगता है, मजबूत राय कमजोर रूप से आयोजित की जाती हैं।

ScottFreeCode 9 नव॰ 2016

आईएमओ null मानों को गैर-मौजूदा मानों के रूप में व्याख्या करना गलत है।

{ name: null }

उस वस्तु में एक name संपत्ति एक मिथ्या मूल्य के साथ है, और इसलिए इसे कभी भी अमान्य के रूप में नहीं देखा जाना चाहिए और इसलिए फेंकने का कोई कारण नहीं है।

एक अधिक उपयुक्त जाँच यह जाँचने के लिए होगी कि क्या अनुरोधित संपत्ति को परिभाषित किया गया है जैसे हम मूंछ में करते हैं।

phillipj 9 नव॰ 2016

👍1

लेकिन दूसरे में यह उम्मीद कर सकता है कि डेटा उपलब्ध हो सकता है या नहीं भी हो सकता है और शाखा है कि यह है (जिस स्थिति में यह कभी भी अमान्य नहीं है)।

मैं जो बताने की कोशिश कर रहा था, वह यह है कि, यदि आप कुंजी X (उदाहरण के लिए {{#X}} आधार पर शाखा करते हैं, तो प्रदान किए गए डेटा में कुंजी X लिए एक मान होना चाहिए, या तो एक सत्य या मिथ्या मूल्य, लेकिन निश्चित रूप से नहीं undefined ।

null अर्थ है "हाँ, मुझे पता है कि कोई मूल्य नहीं है। मैं स्पष्ट रूप से चिह्नित कर रहा हूं कि कोई मूल्य नहीं है"।
undefined अर्थ है कि कुंजी X को परिभाषित भी नहीं किया गया है (यदि आप undefined मान के साथ एक कुंजी को परिभाषित करते हैं तो आप null का उपयोग करना बेहतर समझेंगे) . और यदि कुंजी को परिभाषित नहीं किया गया है, तो यह या तो 'आलसी' होने के कारण डेटा घोषित कर रहा है (उदाहरण के लिए किसी ऑब्जेक्ट रेफरी की कमी होने पर null का उपयोग नहीं करना) या मानवीय त्रुटि (टाइपो, पर्ची, भ्रम) के कारण

तो, इस मामले में, मैं एक त्रुटि फेंकने में लाभ देखूंगा। (एक कुंजी पर शाखा लगाने की कोशिश कर रहा है जिसका मूल्य है undefined )

दूसरी तरफ, undefined या null प्रस्तुत करने का प्रयास कर रहा है, सुनिश्चित नहीं है कि इसके लिए कोई उपयोग-मामला है या नहीं। शायद उस पर भी एरर।

जब तक यह ऐसे स्रोत से नहीं आ रहा है जो अनुपलब्ध डेटा के लिए शून्य का उपयोग करता है, उदाहरण के लिए SQL

अफैक, मूंछ दर्शन मॉडल का उपयोग करने के लिए नहीं है, बल्कि उनसे 'दृश्य' उत्पन्न करने के लिए है। यदि आपका प्रदाता किसी भी तरह से नहीं करता है तो आप null s जोड़ सकते हैं।

मैं वर्तमान में सोच रहा हूं कि बाहरी/अधिशेष/अप्रयुक्त डेटा वास्तव में डेटा के अमान्य होने का मामला नहीं है, यह टेम्पलेट के अमान्य होने की बात है यदि यह उस डेटा का उपयोग नहीं करता है जब एप्लिकेशन/डेटा/मॉडल इसकी अपेक्षा करता है इस्तेमाल किया गया

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

अगर कुछ सामान वास्तव में उपयोगकर्ता को प्रदर्शित करने की आवश्यकता है, तो यदि टेम्पलेट इसे प्रदर्शित नहीं करता है तो यह एक त्रुटि है

लेकिन कौन/क्या तय करता है कि "उपयोगकर्ता को वास्तव में सामग्री को प्रदर्शित करने की आवश्यकता है"? मैं जिस टेम्पलेट लेखक का अनुमान लगा रहा हूँ? यदि आप लोगों को दृश्य में सभी डेटा का उपयोग करने के लिए बाध्य करते हैं, तो आप उन्हें प्रत्येक टेम्पलेट के लिए एक अनुरूप दृश्य उत्पन्न करने के लिए मजबूर कर रहे हैं जिसे वे प्रस्तुत करना चाहते हैं।

dasilvacontin 9 नव॰ 2016

एक नोट के रूप में: मेरा उपयोग मामला शाखा के बिना मैन्युअल सेटअप था।

मेरे पास 'अन्य लोग' मैन्युअल रूप से डेटा (ईवेंट) बनाते थे और उस स्थिति में मेरे पास यह सत्यापित करने का कोई तरीका नहीं था कि वे सभी फ़ील्ड में भरे हुए हैं या चर-नामों में टाइपो बनाते हैं।

मेरा टेम्प्लेट "{{event.name }} {{event.date}} को" कहेगा। उस स्थिति में एक अनुपलब्ध मान एक भयानक पृष्ठ बना देगा।
सभी फ़ील्ड आवश्यक थे, इसलिए {{event.date}} प्रदर्शित न करने के लिए तर्क जोड़ने का कोई मतलब नहीं होगा।

इस मामले में 'इस्तेमाल नहीं किया गया' चर भी जानना अच्छा होगा, टाइपो के लिए दोबारा जांच करने के लिए या उन वस्तुओं के लिए जो उन्होंने सोचा था कि वे पृष्ठ पर 'जादुई' दिखाई देंगे :)

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

९ नवंबर २०१६ को १०:५३ बजे डेविड डा सिल्वा नोटिफिकेशन @github.com ने लिखा:
लेकिन दूसरे में यह उम्मीद कर सकता है कि डेटा उपलब्ध हो सकता है या नहीं भी हो सकता है और शाखा है कि यह है (जिस स्थिति में यह कभी भी अमान्य नहीं है)।
मैं जो बताने की कोशिश कर रहा था, वह यह है कि, यदि आप कुंजी X (जैसे {{#X}} के आधार पर शाखा करते हैं, तो प्रदान किए गए डेटा में कुंजी X का मान होना चाहिए, या तो एक सत्य या गलत मान, लेकिन निश्चित रूप से अपरिभाषित नहीं है।
शून्य का अर्थ है "हाँ, मुझे पता है कि कोई मूल्य नहीं है। मैं स्पष्ट रूप से चिह्नित कर रहा हूं कि कोई मूल्य नहीं है"।
अपरिभाषित ज्यादातर का तात्पर्य है कि कुंजी एक्स को परिभाषित भी नहीं किया गया है (यदि आप अपरिभाषित के मान के साथ एक कुंजी को परिभाषित करते हैं तो आप शून्य का उपयोग करना बेहतर होगा)। और यदि कुंजी को परिभाषित नहीं किया गया है, तो यह या तो 'आलसी' होने के कारण डेटा घोषित कर रहा है (उदाहरण के लिए ऑब्जेक्ट रेफरी की कमी होने पर शून्य का उपयोग नहीं करना) या मानवीय त्रुटि (टाइपो, पर्ची, भ्रम) के कारण
तो, इस मामले में, मैं एक त्रुटि फेंकने में लाभ देखूंगा। (एक कुंजी पर शाखा लगाने की कोशिश कर रहा है जिसका मूल्य अपरिभाषित है)
दूसरी तरफ, अपरिभाषित या शून्य को प्रस्तुत करने का प्रयास कर रहा है, सुनिश्चित नहीं है कि इसके लिए कोई उपयोग-मामला है या नहीं। शायद उस पर भी एरर।
जब तक यह ऐसे स्रोत से नहीं आ रहा है जो अनुपलब्ध डेटा के लिए शून्य का उपयोग करता है, उदाहरण के लिए SQL
अफैक, मूंछ दर्शन मॉडल का उपयोग करने के लिए नहीं है, बल्कि उनसे 'दृश्य' उत्पन्न करने के लिए है। यदि आपका प्रदाता किसी भी तरह से नहीं करता है तो आप चारों ओर नल जोड़ सकते हैं।
मैं वर्तमान में सोच रहा हूं कि बाहरी/अधिशेष/अप्रयुक्त डेटा वास्तव में डेटा के अमान्य होने का मामला नहीं है, यह टेम्पलेट के अमान्य होने की बात है यदि यह उस डेटा का उपयोग नहीं करता है जब एप्लिकेशन/डेटा/मॉडल इसकी अपेक्षा करता है इस्तेमाल किया गया
हम्म, मुझे लगता है कि सभी प्रदत्त डेटा का उपयोग नहीं करना बहुत आम है। मैंने मुख्य रूप से टूलिंग बारीकियों के लिए इस विचार को फेंक दिया, जैसे कि मैंने सुझाई गई ग्राफक्यूएल क्वेरी पीढ़ी।
अगर कुछ सामान वास्तव में उपयोगकर्ता को प्रदर्शित करने की आवश्यकता है, तो यदि टेम्पलेट इसे प्रदर्शित नहीं करता है तो यह एक त्रुटि है
लेकिन कौन/क्या तय करता है कि "उपयोगकर्ता को वास्तव में सामग्री को प्रदर्शित करने की आवश्यकता है"? मैं जिस टेम्पलेट लेखक का अनुमान लगा रहा हूँ? यदि आप लोगों को दृश्य में सभी डेटा का उपयोग करने के लिए बाध्य करते हैं, तो आप उन्हें प्रत्येक टेम्पलेट के लिए एक अनुरूप दृश्य उत्पन्न करने के लिए मजबूर कर रहे हैं जिसे वे प्रस्तुत करना चाहते हैं।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603 पर https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe।

MatthijsZw 9 नव॰ 2016

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

दोनों व्यवहार्य लगते हैं। यह सीआई के लिए उपयोगी हो सकता है।

dasilvacontin 9 नव॰ 2016

मैं डिबगिंग के लिए सीधे पैरामीटर को देखना पसंद करूंगा।

antoine-pous 19 फ़र॰ 2017

मेरा उपयोग-मामला थोड़ा अलग है: मैं गुलप का उपयोग करके टेराफॉर्म टेम्पलेट्स को बदलने के लिए मूंछ का उपयोग करता हूं। एक लापता चर इंस्टेंस को सही ढंग से बूट नहीं करने का कारण बन सकता है, खासकर जब फ्री-फॉर्म स्ट्रिंग्स में प्रतिस्थापित किया जाता है। मैं इस कार्यक्षमता को प्राप्त करने के लिए एक त्वरित बंदर-पैच के साथ आया लेकिन यह शायद ही आदर्श है:

var mustache = require("mustache");

var errors = [];
var lookup = mustache.Context.prototype.lookup;

mustache.Context.prototype.lookup = function(name) {
    var value = lookup.bind(this)(name);

    if (value === undefined) {
        console.error("Unknown symbol", name);
        errors.push(name);
    }

    return value;
}

var render = mustache.render;

mustache.render = function(template, view, partials) {
    var result = render.bind(this)(template, view, partials);

    if (errors.length > 0) {
        throw {message: "Unknown symbols: " + errors.join(", ")};
    }

    return result;
}

टिप्पणियाँ:

यह आपको लाइन नंबर या पूरी तरह से योग्य प्रतीक नाम नहीं देता है
यदि आप बहु-थ्रेडेड वातावरण में काम कर रहे हैं तो यह शायद पूरी तरह से असुरक्षित है

हालाँकि इसने मेरे उद्देश्यों के लिए अच्छा काम किया और मुझे यकीन है कि यदि आवश्यक हो तो कोई इसे अनुकूलित कर सकता है।

steverukuts 11 जन॰ 2018

👍3

किसी भी प्रकार के कॉन्फ़िगरेशन प्रबंधन वातावरण में मूंछों को टेम्प्लेटिंग इंजन के रूप में उपयोग करने के लिए लापता चर पर कठिन त्रुटियों की आवश्यकता होती है। मेरे पास @steverukuts के समान उपयोग का मामला है, कुबेरनेट्स परिनियोजन दस्तावेज़ों को बदलना। इस उपयोग के मामले में गुम चर हमेशा त्रुटियां होती हैं।

stefaneg 20 अप्रैल 2019

@stefaneg लिखने के कुछ महीने बाद वास्तव में मुझे पता चला कि टेराफॉर्म JSON प्रारूप में लिखे गए कॉन्फ़िगरेशन का समर्थन करता है, इसलिए अब मैं मूंछों का उपयोग करने के बजाय इसका उपयोग करता हूं। यह बहुत बेहतर और अधिक प्रोग्राम करने योग्य है। हमने अब इसके लिए मूंछों के उपयोग को हटा दिया है और इसे हमारी परिनियोजन पाइपलाइन के अगले संशोधन में हटा दिया जाएगा।

Kubernetes परिनियोजन दस्तावेज़ों को देखने के बाद मैंने देखा कि ये YAML फ़ाइलें हैं। अधिकांश प्रोग्रामिंग भाषाओं में पुस्तकालय होते हैं जो YAML को पढ़ और लिख सकते हैं, इसलिए मेरा सुझाव है कि आप इसके बजाय ऐसा करें। अपने प्रयोग से, मैंने सीखा है कि जब आप एक मशीन पठनीय प्रारूप में हेरफेर करने की कोशिश कर रहे हैं, तो आपके पास लगभग हमेशा मूंछ से बेहतर विकल्प होता है।

कृपया ध्यान दें: जबकि मैं अब किसी भी चीज़ के लिए मूंछों का उपयोग नहीं करता, फिर भी मुझे लगता है कि यह एक वैध सुविधा अनुरोध है।

steverukuts 20 अप्रैल 2019

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

@steverukuts आप मैनिपुलेटिंग मशीन पठनीय प्रारूप के बारे में सही हैं, यदि आपके पास पूर्व निर्धारित हेरफेर है जिसे आपको समर्थन देने की आवश्यकता है, और विशेष रूप से यदि आपको इसमें कुछ स्मार्ट बनाने की आवश्यकता है। एक ओपन एंडेड कॉन्फ़िगरेशन टूल के लिए, जो बहुत तेजी से अनम्य हो जाता है, इसलिए टेम्प्लेटिंग की आवश्यकता होती है। मनमाने स्थानों में मनमाने मूल्यों को सम्मिलित करने का समर्थन करने वाला एक उपकरण लिखने का प्रयास करें और ... आपके पास बहुत जल्द एक टेम्प्लेटिंग इंजन है।

stefaneg 23 अप्रैल 2019

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

ऊपर चर्चा के संबंध में; यह अज्ञात चरों पर भी फट जाएगा।

phillipj 24 अप्रैल 2019

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

इस मुद्दे ने मुझे हैंडलबार का भी उपयोग करने के लिए मजबूर किया। यह बहुत बुरा है यह मूंछों में समर्थित नहीं है।

killdash9 29 अप्रैल 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Mustache.js: विकल्प जोड़ें: अज्ञात चर पर चेतावनी

सबसे उपयोगी टिप्पणी

सभी 18 टिप्पणियाँ

संबंधित मुद्दों