ट्यूटोरियल डर्बी.जेएस

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

इसके बजाय अग्रदूत

पोस्ट को Habré पर टिप्पणियों और संदेशों में प्रश्नों के आधार पर लिखा गया है।
मेरा मानना ​​है कि आप पहले से ही डर्बी से परिचित हैं और अपना पहला हैलो वर्ल्ड बनाया है । यदि नहीं, तो मैं इसे अभी करने की सलाह देता हूं। यहाँ टिप्पणियों के साथ कुछ नमूना अनुप्रयोग हैं । यहाँ के लिए हम सामान्य, मुश्किल बात के बारे में बात करेंगे।
कोड उदाहरण Coffeescript हैं। मुझे उम्मीद है कि केवल js से परिचित लोग ही इससे परेशान नहीं होंगे।
उदाहरण के लिए मैं 12341243 फॉर्म में आईडी का उपयोग करता हूं। वास्तव में यह मार्गदर्शक होगा।

डर्बी ऐप

प्रत्येक डर्बी आवेदन एक बढ़ाया एक्सप्रेस आवेदन है। यही है, आप connect.js, सर्वर मार्गों आदि का उपयोग कर सकते हैं, जैसा कि आप एक नियमित एक्सप्रेस एप्लिकेशन में करते हैं।
एक डर्बी एप्लिकेशन में एक सर्वर एप्लिकेशन (एक्सप्रेस) और एक या अधिक क्लाइंट एप्लिकेशन होते हैं। उदाहरण के लिए, आप उपयोगकर्ताओं और व्यवस्थापक पैनल के लिए साइट को अलग कर सकते हैं, और उपयोगकर्ताओं को व्यवस्थापक पैनल से टेम्पलेट और व्यावसायिक तर्क के साथ लोड नहीं कर सकते।

पहला निवेदन

क्लाइंट से पहले अनुरोध पर, वांछित मार्ग सर्वर पर संसाधित होता है और उत्पन्न HTML क्लाइंट को डर्बी एप्लिकेशन (टेम्पलेट, मॉडल, मॉड्यूल के साथ ब्राउजर, व्यापार तर्क) के साथ एक साथ भेजा जाता है। क्लाइंट पहले html देखता है, और बाकी सब कुछ अगले लोड होता है। भविष्य में, url बदलते समय, मार्गों को क्लाइंट पर संसाधित किया जाएगा और उसी स्थान पर html उत्पन्न किया जाएगा। यदि ब्राउज़र में js अक्षम है, तो रूट केवल सर्वर पर संसाधित होते हैं और HTML हमेशा सर्वर पर उत्पन्न होता है, एक नियमित स्थैतिक साइट की तरह।

मार्गों

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

एचटीएमएल

डर्बी में एक अंतर्निहित टेम्पलेट इंजन है - थोड़ा संशोधित हैंडलबार । जेड के लिए एक मॉड्यूल है।

डेटा का एक गुच्छा निम्नानुसार किया जाता है:
डायनामिक (HTML परिवर्तन और इसके विपरीत डेटा में परिवर्तन)

<input type="text" value="{_page.name}" />, <h2>{users.12431243.age}</h2> 

स्थिर (वापस ले लिया और भूल गया)

 <input type="text" value="{{_page.name}}" />, <h2>{{users.12431243.age}}</h2> 

टेम्प्लेट में अनुभाग होते हैं: Tille, Head, Body, Footer, Scripts, आदि। आप उदाहरण के लिए, लेआउट टेम्पलेट में हेड और लिपियों को निर्दिष्ट कर सकते हैं (यदि वे सभी पृष्ठों के लिए समान हैं), और अन्य में केवल शीर्षक और बॉडी निर्दिष्ट करते हैं।

आदर्श

मॉडल डेटा के साथ काम करने के लिए एपीआई के साथ एक वस्तु है। सभी डेटा जोड़तोड़ इसके माध्यम से होते हैं।
मॉडल सर्वर और क्लाइंट दोनों पर मौजूद हो सकता है। सर्वर पर कई मॉडल हो सकते हैं, केवल क्लाइंट पर एक।
सर्वर पर मॉडल प्रत्येक अनुरोध के लिए बनाए जा सकते हैं

 model = req.getModel() 

या स्टोर से अनुरोधों की परवाह किए बिना

 model = store.createModel() 

क्लाइंट पर, मॉडल हमेशा यहाँ है:

 model = require('derby').app.model 

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

पथ

सभी डेटा पथ के रूप में प्रस्तुत किए जाते हैं, जिसमें इस ऑब्जेक्ट के संग्रह, आईडी और गुणों के नाम शामिल हैं।
उदाहरण के लिए:

 user = model.get 'users.12341234' userName = model.get 'users.12341243.name' model.set 'customers.12341234.properties.isIdiot', true model.set 'customers.12341243.properties', {justMadeOrderForBillionDollars: true, isIdiot: false} 

लायें, सदस्यता लें

मॉडल बनाते समय, यह खाली है।

 emptyObject = model.get() 

इसे लाने और डेटा को सब्सक्राइब करने के दो तरीके हैं।
लाने - बस डेटाबेस से डेटा खींचता है और इसे मॉडल में डालता है।

 model.fetch 'product.12341243', 'users', -> console.log '        ' 

सदस्यता - गतिशील रूप से मॉडल में डेटा के साथ डेटाबेस से डेटा बांधता है

 model.subscribe 'products', -> console.log '  ' 

अब अगर हम मॉडल में डेटा बदलते हैं

 model.add 'products', {name: 'Awesome brand new product'} 

फिर इन परिवर्तनों को डेटाबेस में भी दर्ज किया जाएगा। और अगर अन्य मॉडल (अन्य क्लाइंट या सर्वर पर) इस डेटा की सदस्यता लेते हैं, तो इन मॉडलों में परिवर्तन भी जोड़े जाएंगे।

प्रश्नों

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

 ids = model.get '_page.ids' $customersWithSomeIdQuery = model.query 'customers', {'id' => { "$in" => ids}} model.subscribe $customersWithSomeIdQuery, -> myCustomers = model.get $customersWithSomeIdQuery 

प्रत्येक db के लिए, क्वेरी सिंटैक्स अलग होगा। इस मामले में, मैंगो प्रश्न।

दुकान

एकल कॉपी में सर्वर पर एक ऑब्जेक्ट जिससे सभी मॉडल बनाए जाते हैं और जिसमें सभी जादू होता है।
स्टोर सभी मॉडलों के साथ जुड़ा हुआ है। ग्राहकों पर मॉडल के साथ संवाद करने के लिए, एक ब्राउज़रचैन का उपयोग किया जाता है। वेब सॉकेट्स का उपयोग नहीं किया जाता है क्योंकि वे संदेश वितरण के आदेश की गारंटी नहीं देते हैं, जो ओटी के लिए बेहद महत्वपूर्ण है। Gmail में उपयोग किया जाने वाला ब्राउज़रचैन "Google से socket.io" है।
Share.js का उपयोग करके क्लाइंट के डेटा को डेटाबेस में मिला दिया जाता है, यह ऑपरेशनल ट्रांसफ़ॉर्मेशन का कार्यान्वयन है। आपको डेटा के संस्करण को देखते हुए संघर्षों को हल करने की अनुमति देता है। ग्राहक लंबे समय तक ऑफ़लाइन जा सकते हैं, अपने मॉडल में डेटा बदल सकते हैं, जिसके बाद उनका डेटा डेटाबेस में दर्ज किया जाएगा, इस समय के दौरान अन्य ग्राहकों से परिवर्तन को ध्यान में रखते हुए। यह एक समय में Google वेव्स में कैसे काम करता है (OT में share.js और Google Waves एक व्यक्ति द्वारा लिखा गया है) के समान है।

लाइव डी.बी.

लाइव-डीबी शेयर.जेएस के लिए एक डेटा वेयरहाउस है। दो भागों से मिलकर बनता है:
1) रेडिस - आवश्यक। Share.js ग्राहकों को सिंक्रनाइज़ करने के लिए रेडिस पब-उप का उपयोग करता है, क्योंकि यह मोंगो में पब-उप में कई प्रतिबंधों का परिचय देता है (संग्रह एक निश्चित आकार का होना चाहिए) , इसलिए इसकी गति और प्रतिबंधों की कमी के साथ रेडिस इसके लिए आदर्श है। रेडिस में भी हाल के ऑपरेशनों का एक कैश है (आप निर्दिष्ट करें कि कितना)। यह कैश आपको लंबे समय तक ऑफ़लाइन रहने वाले ग्राहकों के डेटा को मर्ज करने की अनुमति देता है।
2) डेटा स्वयं किसी भी डेटाबेस में संग्रहीत किया जा सकता है। लेकिन फिलहाल केवल Mongo DB के लिए एक एडेप्टर है। एडेप्टर लिखना बहुत आसान है।
सभी ऑपरेशन के इतिहास को संग्रहीत नहीं किया जा सकता है, डेटा के रूप में एक ही डेटाबेस में संग्रहीत किया जा सकता है, दूसरे डेटाबेस में संग्रहीत किया जा सकता है।

आर्किटेक्चर

नीचे से ऊपर:
लाइव-डीबी एक इवेंट डेटाबेस बनाने के लिए रेडिस और मोंगो पर एक आवरण है।
share.js लाइव-डीबी का उपयोग करके ओटी है
रेसर डेटा के साथ काम कर रहा है: स्टोर, मॉडल। Share.js के आधार पर
डर्बी मार्ग (ट्रैक), टेम्पलेट, दृश्य हैं।

आप लाइव-डीबी, शेयर.जेएस, रेसर, ट्रैक्स, आदि भागों का अलग-अलग उपयोग कर सकते हैं। आप रेसर को share.js, या share.js से अलग से लाइव-डीबी से उपयोग नहीं कर सकते। आप रेबीर से अलग से डर्बी का उपयोग नहीं कर सकते, क्योंकि डर्बी रेसर डेटा मॉडल के लिए बाध्य है।

स्केलिंग

आप एक डेटाबेस (लाइव-डीबी) के साथ काम करते हुए कई डर्बी एप्लिकेशन (प्रत्येक अपने स्टोर के साथ) चला सकते हैं।

अन्य क्या कठिनाइयाँ हैं?

Derby.js द्वारा सामग्री