2017-03-17 8 views
6

में चयनकर्ता स्लिंग में चयनकर्ताओं का उपयोग क्या है?एईएम

http://www.resourcePathचयनकर्ता .extension

मैं चयनकर्ताओं के उपयोग के बारे में ऑनलाइन दस्तावेज़ों को पढ़ लिया है:

  1. दस्तावेजों के कुछ लोग कहते हैं कि यह एक पृष्ठ जब नहीं किया जा सकता से कैशिंग प्रतिक्रिया के लिए प्रयोग किया जाता है क्वेरी पैरामीटर का उपयोग कर।

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

लेकिन मुझे यकीन नहीं है कि इनमें से कौन सा सत्य है।

किसी भी मार्गदर्शन के लिए अग्रिम धन्यवाद।

उत्तर

7

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

ये ज्यादातर कार्यान्वयन पर निर्भर हैं लेकिन सामान्य सम्मेलन उन्हें स्थान के आधार पर व्याख्या करना है।

अच्छा सरल उदाहरण tree.json की होगी

tree.1.json (1 गहराई चयनकर्ता है) सिर्फ tree.json कह का एक और तरीका है? गहराई = 1

इसी तरह पेड़। 2.json पेड़ की तरह है। जेसन? गहराई = 2

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

ऊपर के प्रकाश में, यहाँ आपके प्रश्नों (पोस्ट संपादित करें) के लिए सीधी प्रतिक्रिया है:

दस्तावेजों के कुछ लोग कहते हैं कि यह एक पेज से कैशिंग प्रतिक्रिया है जो जब क्वेरी पैरामीटर का उपयोग नहीं किया जा सकता है के लिए प्रयोग किया जाता है ।

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

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

कोड देख के बिना, मैं यह सोचते हैं हूँ कुछ इस तरह था:

page.last-page.html

जहां last-page चयनकर्ता आप प्रतिक्रिया को अलग करने के लिए प्रयोग किया जाता है। यह करने का यह एक तरीका है और जब तक पृष्ठ कैश किया जा सकता है, तब तक इस चयनकर्ता संस्करण को बिना किसी समस्या के कैश किया जा सकता है। यह यूआरएल अर्थशास्त्र का एक अच्छा उपयोग है और कैशिंग मुद्दों से परहेज करता है। यदि यह के रूप में लागू किया गया था:

page.html?last-page=true

यह कैश अनुकूल नहीं किया गया है हो सकता है।

स्लिंग के पास किसी URL पर स्क्रिप्ट या सर्वलेट को बाध्यकारी (हल करने) के विभिन्न तरीके हैं। यह संकल्प विस्तार, चयनकर्ता और/या पथ के आधार पर किया जाता है। मौजूदा सर्लेट को संशोधित किए बिना आप नए चयनकर्ता आधारित सर्लेट बनाकर किसी मौजूदा चयनकर्ता या एक्सटेंशन में नई कार्यक्षमता जोड़ सकते हैं। एक उदाहरण सर्वलेट पर विचार करें जो पथ के लिए JSON डेटा देता है (हम जानते हैं कि यह एईएम में ओओटीबी मौजूद है लेकिन केवल एक उदाहरण है)। नोड के

content/mypage.json

रिटर्न JSON प्रतिनिधित्व।

अब, मान लीजिए कि आप एक नया JSON प्रारूप चाहते हैं जो कि टियरियर है। परंपरा क्वेरी स्ट्रिंग का उपयोग करके आप आप मूल सर्वलेट के स्रोत कोड तक पहुंच नहीं है, तो जैसे

content/mypage.json?tidy=true

यह कुछ करना संभव नहीं हो सकता होगा। तो वैकल्पिक हल होगा:

content/mypage.tidy.json

यह एक नया सर्वलेट जो tidy चयनकर्ता स्वीकार करता है और समारोह को ओवरराइड करता है हो सकता है। स्क्रिप्ट रिज़ॉल्यूशन और कोड एक्सटेंशन की बात आती है जब यह चयनकर्ता शक्तिशाली बनाता है। हां आप इसे क्वेरी पैरामीटर के साथ भी कर सकते हैं लेकिन सीमाएं तब तक होंगी जब तक कि आप सभी कोड के स्वामी न हों।

+0

तो क्या इसका मतलब यह है कि चयनकर्ताओं के पास क्वेरी पैरामीटर के समान सटीक कार्य होता है (यानी किसी फ़ंक्शन को पैरामीटर पास करने के लिए)। लेकिन कैचिंग के आसपास उनका उपयोग केवल अंतर है? –

+1

संक्षेप में, हां। हालांकि, वे क्वेरी स्ट्रिंग पैरामीटर के प्रतिस्थापन नहीं हैं। आपका यूआरएल अभी भी चयनकर्ताओं की उपस्थिति में क्वेरी स्ट्रिंग पैरामीटर का उपयोग कर सकता है। यह कैशिंग को बढ़ाता है और यूआरएल को एक बेहतर अर्थात् संरचना प्रदान करता है (आईएमएचओ)। –

+0

मेरे प्रश्न में बिंदु 2 के बारे में क्या? क्या यह चयनकर्ताओं का मुख्य उपयोग नहीं है? –