ऑटोडाफ़ में रूटिंग का अनुरोध करें

ऑटोडाफ़े - नोड.जेएस फ्रेमवर्क, इस लेख में शुरू: habrahabr.ru/blogs/nodejs/135089

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

धूल कहां से आती है

आइए ग्राहकों को एप्लिकेशन से कनेक्ट करने वाले आरेख के साथ शुरू करें:



आरेख में, आप कई उपयोगकर्ताओं को देख सकते हैं जो विभिन्न उपकरणों और विभिन्न ब्राउज़रों का उपयोग करते हैं, जो बदले में विभिन्न प्रोटोकॉल के माध्यम से आवेदन से जुड़ते हैं। (वर्तमान में, आप केवल http और websockets के माध्यम से ऑटोडाफे से कनेक्ट कर सकते हैं)

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

खैर, एक तार्किक निष्कर्ष के लिए, "उपयोगकर्ता" घटक आरेख में दिखाया गया है, जो आपको विभिन्न सत्रों को बांधने की अनुमति देता है जो किसी उपयोगकर्ता विशेष ऑब्जेक्ट के लिए विशेष प्राधिकरण पारित कर चुके हैं। इस प्रकार, एप्लिकेशन में, प्रत्येक UserIdentity ऑब्जेक्ट एक वास्तविक उपयोगकर्ता के साथ जुड़ा हुआ है।

पैसा कहां जाता है

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

इस प्रकार: किसी भी प्रोटोकॉल का उपयोग करने वाले प्रत्येक अनुरोध को एक स्थान पर वर्णित तालिका का उपयोग करके पुनर्निर्देशित किया जाता है

रूटिंग टेबल

रूटिंग टेबल में, आप निर्दिष्ट कर सकते हैं:

• बेशक, मार्ग एक विशिष्ट नियंत्रक की कार्रवाई के लिए अनुरोधों को पुनर्निर्देशित करते हैं
• कस्टम URL पैरामीटर
• तरीके और प्रोटोकॉल, जिनके लिए ये क्रियाएं उपलब्ध हैं
• होस्ट से पुनर्निर्देशन जिस पर अनुरोध आया था, वह किस पोर्ट पर आया था, आदि।

राउटिंग टेबल न केवल अनुरोध को पार्स करने का काम करता है, बल्कि सर्वर पर URL जनरेट करने का भी काम करता है, जो आपको लचीले ढंग से URL के रूप को बदलने देता है, जिससे एक ही स्थान पर संपादन हो जाता है।

नियंत्रक साधारण वर्ग हैं। क्रियाएं विधियां हैं। यदि राउटिंग टेबल में यह निर्दिष्ट नहीं है तो कोई अनुरोध काम नहीं करेगा। इस प्रकार, नियंत्रक विधियाँ जो क्रिया नहीं हैं, कहलाने से सुरक्षित हैं।

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

router : { rules : { '' : 'site.index' } } 

नियम अनुभाग की कुंजियाँ url पते के भाग से मेल खाती हैं जो होस्ट नाम के बाद और अनुरोध मापदंडों से पहले आता है, इसलिए url पते के लिए www.example.com/messages/unread?user_id=5 यह भाग संदेशों या अपठित के बराबर है।

मान नियम - यह उस क्रिया का पथ है जो 'नियंत्रक.संक्रमण' के रूप में इस अनुरोध के लिए किया जाना चाहिए।

 router : { rules : { '' : 'site.index', 'messages/unread' : 'dialogs.show_unread_messages' } } 

URL निर्माण

नियंत्रक कोड में, वांछित URL बनाने के लिए, create_url विधि का उपयोग करें:

 this.create_url( 'dialogs.show_unread_messages' ); //  '/messages/unread' 

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

 <a href="{#url}dialogs.show_unread_messages{/url}"> </a> 

पासिंग पैरामीटर

नियंत्रक के अंदर एक लिंक बनाना:

 this.create_url( 'dialogs.show_unread_messages', { user_id : 5 } ); //  '/messages/unread?user_id=5' 

देखने में:

 <a href='{#url user_id="5"}dialogs.show_unread_messages{/url}'> </a> 

हमने मापदंडों को पथ में रखा

नीचे पंक्ति: बारी / संदेश / अपठित? उपयोगकर्ता_द = 5 में / संदेश / अपठित / उपयोगकर्ता / 5

नियम अनुभाग:

 rules : { '/messages/unread/user/<user_id:\\d+>' : 'dialogs.dialogs.show_unread_messages' } 

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

हम अनुरोधों को फ़िल्टर करते हैं

उदाहरण के लिए, कुछ कार्यों को करने की आवश्यकता होती है, केवल तभी जब वे POST अनुरोध के माध्यम से या WebSockets के माध्यम से आए हों। इसे सीधे तालिका में निर्दिष्ट किया जा सकता है।

 rules : { //       POST 'update_message' : 'dialogs.update_message | post' } 

पोस्ट की जगह डिलीट और ws प्राप्त कर सकते हैं। उत्तरार्द्ध केवल वेबसॉकेट के माध्यम से प्राप्त कार्यों के लिए कॉल को प्रतिबंधित करता है

विधियों को अल्पविराम से समूहीकृत किया जा सकता है:

 rules : { //       POST 'delete_message' : 'dialogs.delete_message | post, delete' } 

अंतराल को ध्यान में नहीं रखा जाता है, इसलिए आप आसानी से एक सुंदर दृश्य में सब कुछ संरेखित कर सकते हैं

डोमेन नाम और पोर्ट द्वारा फ़िल्टर अनुरोध

 rules : { 'hostname:m.domain.com port:3000 /' : 'mobile.index' } 

अधिक विस्तार से इस विषय का खुलासा आगामी साइट में प्रलेखन के साथ किया जाएगा।

आपका ध्यान देने के लिए धन्यवाद।

पुनश्च:

गिथुब स्रोत कोड: ऑटोडाफे
ट्विटर फ्रेमवर्क @node_autodafe का पालन करें

यदि आप विकास में भाग लेना चाहते हैं या किसी भी तरह से ढांचे के विकास में मदद करना चाहते हैं - PM पर लिखें या gife.com पर jifeon पर