dash-b · विशेषताहरू · क्लिकमा
केही गर्ने dashboard।
धेरैजसो dashboard हरू संरचनात्मक रूपमा read-only हुन्छन्: तिनीहरू तपाईंलाई एउटा सङ्ख्या देखाउँछन् र त्यसमा कारबाही गर्न अर्को ठाउँ जाने जिम्मा तपाईंलाई दिन्छन्। dash-b को tile मा बटन हुन सक्छ, र त्यसलाई थिच्दा row थपिन्छ, अपडेट हुन्छ, वा तपाईंकै टेबलबाट बनेको फारम खुल्छ।
दुई टाइलहरू
एउटा बटन, वा एउटा फारम
कारबाही
तपाईंले रोजेको लेबल भएको एउटा बटन। यसले तपाईंकै टेबलहरू मध्ये एउटामा एक नामाङ्कित operation चलाउँछ — आजको आम्दानी बैंकमा पुग्यो भनी चिनो लगाउने, shift थप्ने, ticket बन्द गर्ने। टाइप गर्न केही छैन, एक थिचाइ।
डेटा फारम
operation लाई विवरण चाहिने बेलाको त्यही कुरा। फिल्डहरू design ले घोषणा गरेको कुराबाट होइन, टेबलकै schema बाट बन्छन्, त्यसैले तपाईंले column को नाम बदल्दा फारम बदलिन्छ र हटाइएको column मागिँदैन।
क्रिया भनेको के हो
तीन कुञ्जी, र चौथो नाइँ
action ले एउटा operation नामाङ्कित गर्छ, त्यसले केमा काम गर्छ भन्ने नामाङ्कित गर्छ, र parameters पठाउँछ। पूरा शब्दावली यही हो:
- command एउटा registry मा भएको index हो, जसमा dash-b को आफ्नै code ले मात्र थप्न सक्छ। design ले नयाँ command बनाउन सक्दैन।
- binding एउटा नाम हो, जुन बटन थिचिँदा तपाईंकै खातामा भएका documents विरुद्ध resolve हुन्छ। कसैले पठाएको design ले तपाईंसँग नभएको टेबलको नाम लिएको छ भने त्यो रोकिन्छ र त्यसो भन्छ।
- parameters एउटा literal हुन्, वा फारम, tile वा थिचाइबाट पढिने एक नामाङ्कित मान। एक तह गहिरो मात्र, र त्योभन्दा बढी केही होइन।
action भित्र लेखिएको URL, header, token वा role मृत कुञ्जी हो।
dash-b भित्र कुनै कुराले तिनीहरू पढ्दैन। एउटा test ले चारवटै बोकेको action पठाउँछ र कुनै पनि handler सम्म नपुगेको जाँच गर्छ।
शब्दावली जानाजान कमजोर राखिएको छ। parameter भाषामा थपिने प्रत्येक operator अपरिचित मानिसहरूले एक-अर्कालाई पठाउने फाइलभित्र rules engine बस्न तिर एक कदम हो, र design फाइल अरूको logic चलाउने ठाउँ होइन।
लेखाइले पालना गर्ने नियमहरू
यी मध्ये तीनवटा dash-b को बाँकी व्यवहारको उल्टो छन्
अज्ञात आदेश ठूलो त्रुटि हो
अरू सबै ठाउँमा नचिनिएको key चुपचाप ignore गरिन्छ, किनभने design ले आफ्नो नयाँ version भेट्दा पनि टिक्नुपर्छ। तर यहाँ होइन: चुपचाप केही नगर्ने write काम गरेको write सँग हुबहु मिल्ने देखिन्छ।
वास्तविक थिचाइ मात्र गनिन्छ
मानिसले वास्तवमै बटन थिच्यो कि थिचेन भन्ने कुरा runtime ले निर्धारण गर्छ, design ले कहिल्यै होइन। कुनै gesture भयो भनी दावी गर्ने design अस्वीकार गरिन्छ।
डेटा परिवर्तन गर्ने जुनसुकै कुरा पुष्टि हुन्छ
Operations read-only, local, वा changing हुन्छन्। Changing ले पहिले सोध्छ — र सोध्नबाट जोगिन सक्दैन — र त्यसलाई एउटा key दिइन्छ जसले दोहोरो थिचाइलाई एक पटकमै सीमित गर्छ।
यो कहाँ देखिँदैन
निर्यात गरिएको HTML पृष्ठमा हुँदैन
design लाई स्वतन्त्र page को रूपमा निर्यात गर्दा बटनहरू त्यसभित्र हुँदैनन्। निर्यातले dash-b को कुनै code चलाउँदैन, त्यसैले त्यहाँको फारमले कसैको टाइप गरेको कुरा सङ्कलन गर्थ्यो र पठाउने ठाउँ कसैको हुँदैन — जुन फारम नै नदिनुभन्दा नराम्रो हो। tile designer र खाताको सुविधा हो, र निर्यातले त्यसलाई छोडेर यही कुरा बताउँछ।
प्रकाशित link को लागि पनि यही कुरा लागू हुन्छ। पाठकले के देख्न सक्छ र के देख्न सक्दैन, त्यो tile कुन डेटासँग बाँधिएको छ भन्नेले निर्धारण गर्छ — sharing कसरी काम गर्छ मा दुवै अवस्था उल्लेख छ।
यसलाई लेख्ने टेबल चाहिन्छ।
त्यो तपाईंको खाताको टेबल हुन सक्छ, वा तपाईंले आफैं होस्ट गरेको connector बाट पुगिने तपाईंकै database — त्यसो भए database को password कहिल्यै हामीसम्म पुग्दैन।