Barista: फ़िल्टरफ़ील्ड 2 - आवश्यकताएँ एकत्रित करना

को निर्मित 6 मई 2020 · 21टिप्पणियाँ · स्रोत: dynatrace-oss/barista

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

डेटा स्रोत

फ़िल्टर फ़ील्ड के डेटा स्रोत में उपलब्ध फ़िल्टर जोड़ने/सेट करने की संभावना

यह परिभाषित करना आसान होना चाहिए कि कौन से फ़िल्टर उपलब्ध हैं, फ़िल्टर प्रकार, उसके बच्चे और सत्यापनकर्ता बताएं। v1 कार्यान्वयन में यह कॉन्फ़िगरेशन ऑब्जेक्ट और डेटा स्रोत के माध्यम से किया जाता है।

उपलब्ध फ़िल्टर को डेटा स्रोत में एसिंक्रोनस रूप से जोड़ने की संभावना

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

चयनित फ़िल्टर (टैग)

एक चयनित फ़िल्टर में एक कुंजी, एक मान और संभावित रूप से कुछ मेटाडेटा होते हैं जो टैग स्थिति को प्रतिबिंबित करेंगे।

टैग कुंजी और मूल्य प्रदर्शन अनुकूलन योग्य होने चाहिए

जैसा कि #1113 में बताया गया है, प्रत्येक व्यक्तिगत टैग के अंदर प्रदर्शित key और संभावित value गुणों को अनुकूलित करने की आवश्यकता है।

चयनित फ़िल्टर प्रोग्रामेटिक रूप से सेट करना आसान होना चाहिए

v1 कार्यान्वयन में फ़िल्टर केवल उन तत्वों के संदर्भ में सेट किए जा सकते हैं जो डेटा स्रोत के ऊपर पारित किए गए थे, जो काफी थकाऊ लगता है। (#473 को संदर्भित करता है)

https://github.com/dynatrace-oss/barista/blob/fa98ac150b6d324f5c3eaed990c6d6c5f155f318/libs/examples/src/filter-field/filter-field-programmatic-filters-example/filter-field-programmatic-filters-example.ts# एल67 -एल77

किसी टैग की स्थिति को प्रोग्रामेटिक रूप से बदलना आसान होना चाहिए

वर्तमान में सेट किए गए फ़िल्टर की स्थिति को editable / disabled / read-only में बदलना आसान होना चाहिए। वर्तमान कार्यान्वयन के लिए अभी उपभोक्ता को वर्तमान में सेट किए गए फ़िल्टर प्राप्त करने और उस उदाहरण को खोजने की आवश्यकता है जिसमें वे हेरफेर करना चाहते हैं और वहां परिवर्तन जोड़ना चाहते हैं (# 848 को संदर्भित करता है)।

टैग संपादन योग्य हो सकते हैं

उपयोगकर्ता के लिए पहले से निर्धारित फ़िल्टर में वापस जाना और उसके मान को संपादित करना संभव होना चाहिए।

टैग के बीच तार्किक कनेक्टर

टैग की सूची में तार्किक कनेक्टर, यानी NOT , AND , और OR को जोड़ने का एक आवर्ती अनुरोध है।
इसका उल्लेख करने के लिए @subarroca को धन्यवाद।

तार्किक समूह

टैग के बीच तार्किक कनेक्टर्स के विस्तार के रूप में, @petrabrunner ने यह भी उल्लेख किया कि तार्किक रूप से जुड़े टैग कोष्ठक के भीतर समूह-सक्षम होने चाहिए।

विशिष्टता

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

फ़िल्टर प्रकार और एक्सटेंशन

फिल्टर का नेस्टिंग

फिल्टर नेस्टेबल होने चाहिए, ताकि उपयोगकर्ता को वास्तविक की-वैल्यू पेयर को फिल्टर करने का एक आसान रास्ता मिल सके। यह काफी अच्छी तरह से v1 व्यवहार में परिलक्षित होता है।

एक सेट से चुनें (स्वतः पूर्ण)

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

सुझावों के साथ मुफ़्त टेक्स्ट

कुछ फ़िल्टरों को _just_ उपयोगकर्ता द्वारा परिभाषित एक निःशुल्क टेक्स्ट रखने में सक्षम होना चाहिए। वर्तमान कार्यान्वयन एक पाठ प्रदान करने का विकल्प देता है। टेक्स्ट को कैसे फ़िल्टर किया जाता है, इसका कोई संकेत नहीं है। इस प्रकार के फ़िल्टर में कुछ मोड जोड़ने का विचार हो सकता है, अर्थात startWith , contains , exactMatch । यह उपभोक्ता को फ़िल्टरिंग पर थोड़ा और नियंत्रण दे सकता है।

श्रेणी

v1 कार्यान्वयन में सीमा उपयोगकर्ता को एक या दो मान और इनमें से एक ऑपरेटर चुनने देती है: greater than , less than , equals या range (फ़िल्टर किया गया) मान पहले और दूसरे प्रदत्त मान के बीच होना चाहिए)।
प्रत्येक फ़ील्ड के लिए डिफ़ॉल्ट मान देना संभव होना चाहिए, जो कि सीमा में आबाद है।
पहले से ही समान से अधिक और समान से कम ऑपरेटरों को भी अनुमति देने के लिए सीमा का विस्तार करने का अनुरोध किया गया है। इसके अतिरिक्त रेंज ऑपरेटर मोड में, प्रत्येक मान के लिए greater/less या greater/less than होने का विकल्प भी होना चाहिए।
सीमा को एक विस्तार भी माना जा सकता है।

बहु का चयन

उपभोक्ता के लिए एक बहु-चयन (टैग_ अनुभाग से _select के समान) जोड़ना संभव होना चाहिए, लेकिन एक चयन नहीं, बल्कि एक बहु-चयन सेटअप होना चाहिए। जैसा कि @danielkaneider ने उल्लेख किया है कि यह फ़िल्टर-फ़ील्ड के शुरुआती मोक्स में रहा है और एक ओवरले में एक चेकबॉक्स सूची की तरह दिखता है। (संदर्भ अंक #1206)
मेरी राय में यह कुछ ऐसा होगा जिसे विस्तार के रूप में भी माना जा सकता है।

कस्टम सिमेंटिक अर्थ वाली श्रेणियां

यह भी अत्यधिक एक विस्तार के रूप में निर्मित माना जाता है। कुछ उपयोग के मामले श्रेणी चयन को कवर करते हैं, जो संख्यात्मक श्रेणी तर्क का पालन नहीं करते हैं (यानी, संस्करण संख्या श्रेणियां # 78 में @bmrozinski द्वारा उठाई गई हैं)

फिल्टर के लिए विस्तार

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

वर्तमान में एक विस्तार (प्रथम या तृतीय पक्ष) के माध्यम से किया जाने वाला माना जाता है:

श्रेणी
अर्थ अर्थ के साथ पर्वतमाला
बहु का चयन
खजूर बीनने वाला

मान्यकरण

प्रत्येक सबमिट किए गए फ़िल्टर को फिर से पास किए गए सत्यापनकर्ता कार्यों को मान्य करने में सक्षम होना चाहिए। v1 कार्यान्वयन में, यह केवल free-text प्रकार के लिए ही संभव था।

इनपुट फ़िल्टरिंग

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

कोणीय प्रपत्र एकीकरण के लिए समर्थन

https://github.com/dynatrace-oss/barista/issues/951#issuecomment -631519841 के आधार पर इसकी जांच की जानी चाहिए कि क्या कोणीय रूपों के साथ एकीकरण संभव होगा (फ़िल्टर फ़ील्ड मान काफी जटिल हो सकते हैं)। लेकिन यह निश्चित रूप से गौर करने वाली बात है।

filter-field needs discussion

स्रोत

tomheller

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

नमस्कार!

हमें एक अन्य पहलू पर कुछ फीडबैक प्राप्त हुआ जिसे सुधारा जा सकता है, अर्थात् फिल्टर मध्यम/लंबे टेक्स्ट इनपुट से कैसे निपटता है।

वर्तमान में विजेट लगभग 24-25 वर्णों का एक इनपुट "विंडो" प्रस्तुत करता है जिससे उस टेक्स्ट की समीक्षा करना थोड़ा मुश्किल हो जाता है जिसे कोई इनपुट या कॉपी-पेस्ट करता है।
उदाहरण के लिए विजेट विस्तार कर सकता है और इसके दाईं ओर खाली स्थान का उपयोग कर सकता है, विशेष रूप से बड़ी स्क्रीन पर।

Screenshot 2020-10-23 at 09 29 30

नीला बॉक्स इनपुट बॉक्स के आकार को हाइलाइट करता है, उदाहरण टेक्स्ट है: _यह एक मध्यम लंबा टेक्स्ट है_

giordy 23 अक्तू॰ 2020

👍2

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

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

OFouda 6 मई 2020

हमें AND, OR और NOT को शामिल करने के लिए कहा गया है।
साथ ही अक्षम राज्य, जिन पर आप पहले से विचार कर रहे हैं

subarroca 6 मई 2020

👍1

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

danielkaneider 6 मई 2020

👍1

हमें AND, OR और NOT को शामिल करने के लिए कहा गया है।

धन्यवाद @subarroca इसे लाने के लिए, मैंने इसे आवश्यकताओं की मूल सूची में जोड़ा है।

प्रारंभिक मॉक में बहु-चयन की कल्पना की गई थी। सुझावों की केवल एक सूची प्राप्त करने और एक का चयन करने के बजाय, आप उन्हें सामने वाले चेकबॉक्स के साथ प्राप्त करेंगे;

धन्यवाद @danielkaneider इसे लाने के लिए। मैंने इसे आवश्यकताओं की मूल सूची में जोड़ा है।

tomheller 6 मई 2020

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

शायद यह आवश्यकताओं में #78 जोड़ने लायक होगा।

Argeath 6 मई 2020

👍1

मैं Filterfield v2 में #78 कार्यान्वयन पर भी भरोसा कर रहा हूं। श्रेणी फ़िल्टर संस्करण संख्या (उदा. 1.194.0) फ़िल्टरिंग से संबंधित मामलों के उपयोग के लिए एकदम सही होंगे।

bmrozinski 6 मई 2020

👍1

मैं Filterfield v2 में #78 कार्यान्वयन पर भी भरोसा कर रहा हूं।

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

tomheller 6 मई 2020

👍1

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

christian-fischer 6 मई 2020

👍1

नमस्ते, यह देखकर बहुत अच्छा लगा कि आप फ़िल्टरफ़ील्ड को एक नया रूप देने की योजना बना रहे हैं;)

हमारे पास जो उपयोगकेस है वह थोड़ा जटिल है, और मुझे नहीं पता कि ऊपर दिए गए सुझाव पहले से ही इसे पूरी तरह से कवर कर चुके हैं या नहीं। हम लॉजिकल-कनेक्टर्स (AND, OR,...) के साथ फ़िल्टर टर्म्स को चेन करने में सक्षम होना पसंद करेंगे

फ़े:
(निर्माता=उपयोगकर्ताx और गंभीरता=उच्च) या (निर्माता=उपयोगकर्ता और गंभीरता=निम्न) के लिए सभी दिखाएं

हम हमेशा इसे "जिस तरह जीरा आपको मुद्दों के लिए फ़िल्टर करने देता है" के रूप में संदर्भित करते हैं।
मैंने पहले ही "एक फ़िल्टर-प्रकार के लिए एकाधिक-चयन" और AND/OR कथन देखे हैं - लेकिन क्या फ़िल्टर-शर्तों को कोष्ठक (या किसी अन्य तरीके से) के साथ परिभाषित करना और उन्हें तर्क-संचालकों के साथ संयोजित करना संभव होगा?

petrabrunner 7 मई 2020

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

मैं उपरोक्त सूची में तार्किक समूहीकरण जोड़ने जा रहा हूं, लेकिन कृपया ध्यान रखें कि यह प्राथमिकताओं की सूची से बहुत नीचे हो सकता है।

tomheller 7 मई 2020

उत्तर के लिए @tomheller thx - tbh। मुझे पहले से ही इसकी उम्मीद थी - क्योंकि तर्क काफी व्यापक होगा - लेकिन मुझे लगा, अगर मैं आपको हमारे उपयोग के बारे में नहीं बताता तो आप इसके बारे में नहीं जानते;)

petrabrunner 7 मई 2020

👍1

हमें स्वत: पूर्ण के लिए आंशिक के रूप में डेटा लोड करने की सुविधा की भी आवश्यकता होगी। उदाहरण के लिए पहले 100 विकल्पों को लोड करें और विकल्प की खोज करते समय फ़िल्टर किए गए विकल्पों को सर्वर से लोड करें।

वर्तमान कार्यान्वयन के लिए पीआर यहां देखा जा सकता है: https://github.com/dynatrace-oss/barista/pull/1021

thomaspink 18 मई 2020

👍1

सभी को नमस्कार, हमारे पास कुछ याचिकाएँ भी हैं, जिन्हें अधिक से कम प्राथमिकता में क्रमबद्ध किया गया है:

श्रेणी फ़िल्टर प्रकारों के लिए डिफ़ॉल्ट न्यूनतम और अधिकतम संख्यात्मक मान सेट करने की क्षमता।
एक नया फ़िल्टर प्रकार: दिनांक पिकर।

धन्यवाद!

airime 18 मई 2020

👍1

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

  interface FilterFormControl {
    field: string;
    value: FilterValue // any basically
    operator?: 'AND' | 'OR' | 'NOT'
    ...
  }

```एचटीएमएल
फॉर्मकंट्रोलनाम = "फ़िल्टर"
लेबल = "इसके अनुसार फ़िल्टर करें"
एरिया-लेबल = "फ़ॉर्म नियंत्रण द्वारा फ़िल्टर करें"
clearAllLabel = "सभी साफ़ करें"

```ts
// comes from a saved config
initFilters = [{
  field: 'foo',
  value: 'bar'
}];
form: FormGroup({
  filter: new FormControl(initFilters)
});

rarenal 20 मई 2020

👍1

नमस्ते,
यह सुविधा होना भी अच्छा होगा:

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

फ़िल्टर केंद्रित नहीं है:
फ़िल्टर केंद्रित (उपयोगकर्ता ने उस पर क्लिक किया):
उपयोगकर्ता टिपिंग:
उपयोगकर्ता टिपिंग समाप्त करता है:
उपयोगकर्ता प्रेस कुंजी दर्ज करें:

SaraDavilaMendez 3 सित॰ 2020

👍2

हैलो टीम! मेरी एक और याचिका भी है, यह परिभाषा होगी:

gettagsForFilterKey (कुंजी: स्ट्रिंग) | DtFilterFieldTag[] | सभी मैचों के साथ DtFilterFieldTag की एक सरणी देता है जहां DtFilterFieldTag की कुंजी में key पैरामीटर होता है
-- | -- | --

टीएल; डीआर: हमारी जरूरतों को बेहतर ढंग से पूरा करने के लिए मौजूदा getTagForFilter फ़ंक्शन का एक नया संस्करण।

airime 28 सित॰ 2020

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

thomaspink 30 सित॰ 2020

🚀1