फ्रेंडली यूआरएल और इसके साथ काम के स्वचालन पर मेरा व्यक्तिगत विचार

नमस्ते

मैं अपनी परियोजनाओं पर अनुकूल URL के कार्यान्वयन के बारे में सामान्य पाठक जानकारी के साथ साझा करना चाहता था।

चर्चा एर्गोनॉमिक्स, वाक्यात्मक सिद्धांतों, समझ और इंटरफेस की उपयोगिता पर केंद्रित होगी। मैं आपको चेतावनी देता हूं, सॉफ्टवेयर कार्यान्वयन पक्ष से, मैं इस विषय को विकसित नहीं करूंगा, क्योंकि हर कोई इसे अलग तरीके से करता है और यहां सच्चाई का पता लगाना काफी मुश्किल है। कोई व्यक्ति प्राप्त किए गए URL की तुलना नियमों के एक समूह से कर सकता है, कोई मेल खा सकता है, कोई यदि आप चाहें, तो .htaccess फ़ाइल को नियमों के साथ जनरेट कर सकते हैं। बात नहीं है।

दृष्टिकोण के प्रकार

पहली बात मैं यह कहना चाहूंगा कि केवल अनुकूल URL के माध्यम से काम करने वाले प्रोजेक्ट्स के बीच के अंतर और मापदंडों और मित्रतापूर्ण रीलों के साथ सीधे रास्तों पर काम करना है।

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

मानव अनुकूल URL सिंटेक्स

मैं "क्या बेहतर है" के विषय पर बहस नहीं करूंगा, क्योंकि इस अवसर पर लोगों ने बार-बार Habré ( http://habrahabr.ru/blogs/searchengines/125103/ , http://habrahabr.ru/blogs/personal/ पर वोट दिया है) 41602 / , http://habrahabr.ru/blogs/personal/35599/ ) मैं केवल अपनी अवधारणा के बारे में बताऊंगा:

1. यदि प्रोजेक्ट पर कई भाषा संस्करण हैं, तो भाषा को URL के पहले घटक (site.com/ru/, site.com/hi/) के रूप में निकाला जाता है। यह संभव है कि भाषा के संस्करणों को डोमेन (site.ru, site.ua, site.kz) में तोड़ दिया जाए, लेकिन मुझे ऐसा लगता है कि यह भाषा संबद्धता की तुलना में एक निश्चित परियोजना के क्षेत्रीय अभ्यावेदन के निर्धारण के लिए अधिक उपयुक्त है।
2. यदि पृष्ठ की मुख्य सामग्री कुछ वस्तुओं की एक सूची है, जिस पर आप जा सकते हैं, तो हम इस पृष्ठ के URL को एक निर्देशिका (site.ru/news/, site.ru/users/, site.ru/catalog/auto/trucks/used/) के रूप में दर्शाते हैं। यह ध्यान रखना महत्वपूर्ण है कि यदि कोई पृष्ठ उन तत्वों की एक सूची है जो (उदाहरण के लिए, डीलरों के पते की एक सूची) पर नेविगेट नहीं किए जाते हैं, तो आपको इसका URL निर्देशिका के रूप में प्रस्तुत नहीं करना चाहिए। यह पदानुक्रम में अंतिम पृष्ठ है। मैं यह भी ध्यान देता हूं कि आपको स्लैश नहीं डालना चाहिए जहां कोई मध्यवर्ती सूची नहीं है, अर्थात, यदि आप URL के अंत से घटक को निकटतम स्लैश में काटते हैं, तो हमेशा प्राप्त URL के अनुरूप एक पृष्ठ होना चाहिए।
3. यदि पृष्ठ की मुख्य सामग्री एक निश्चित पदानुक्रम या सिर्फ एक स्वतंत्र पृष्ठ का अंतिम चरण है, तो एक निश्चित फ़ाइल के नाम के रूप में इसका URL समाप्त करना उचित है। मैं .html पसंद करता हूं, हालाँकि .php क्यों नहीं, बस भ्रम कम है। उदाहरण: /about.html, उपयोगकर्ता / aufry.html, /news/olimpia-2011.html, /catalog/auto/trucks/used/438829.html।
4. बड़ी परियोजनाओं के लिए, यह साइट के वर्गों को उप-डोमेन में विभाजित करने के लिए समझ में आता है, जैसे कि ब्लॉग को एक अलग उप-डोमेन में ले जाना। यह मुझे सुंदर और न्यायसंगत लगता है, खासकर अगर उसी समय ब्लॉग में एक संशोधित डिज़ाइन और अपनी स्वयं की पृष्ठ संरचना हो। शायद कोई कहेगा, "अलग डोमेन पर क्यों नहीं?"। ठीक है, मैं उत्तर दूंगा - ताकि कुकीज़ से पीड़ित न हों, विज्ञापन लिंक पर क्लिक करने की उत्तेजना पैदा न करें।
5. पैराग्राफ 2 (डायरेक्टरीज़) और 3 (अंतिम पृष्ठ) के संबंध में, ऑर्डर, लिमिट, पेज, विभिन्न क्वालिफाइंग पैरामीटर आदि जैसे मापदंडों को रास्ते में रखना बेहद अवांछनीय है। प्रपत्र / कैटलॉग / ब्रश / last_added / page3 / new | red | classic / ... का एक URL एक डराने वाला एहसास पैदा करता है कि आप कहीं बाहर गए हैं जहाँ आप बाहर नहीं निकल सकते। इन मापदंडों को जहां वे होना चाहिए - GET अनुरोध में दें। / कैटलॉग / ब्रश / ऑर्डर? = last_added और पृष्ठ = 3 और निर्दिष्ट करें [रंग] = लाल और निर्दिष्ट करें [शैली] = क्लासिक। यह निश्चित रूप से लंबा है, लेकिन यह स्पष्ट रूप से दिखाई दे रहा है कि पृष्ठ की सामग्री डिफ़ॉल्ट रूप से प्रदर्शित नहीं की गई है, लेकिन कुछ मापदंडों के अनुसार, और आप URL से रास्ता निकालकर उनसे छुटकारा पा सकते हैं।
6. के रूप में। यदि आप MVC आर्किटेक्चर का उपयोग करते हैं, जहां सभी रूपों को उसी नियंत्रक द्वारा संसाधित किया जाता है, जो फॉर्म का निर्माण करता है, तो यह विशेषता कार्रवाई = "" (खाली) निर्दिष्ट करने के लिए इष्टतम है। इसका तात्पर्य यह है कि आप इस फ़ॉर्म के लिए किसी भी प्रकार से अनुकूल URL को नहीं बदलते हैं, डेटा जहाँ जाएगा, उसी के अनुसार टेम्प्लेट आदि में कम संपादन होते हैं।

Rauter

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

1. उपडोमेन - वास्तव में तीसरे स्तर का एक डोमेन है, अगर हमें इसकी आवश्यकता है। यह आमतौर पर खाली होता है।
2. नियम - एक मैच के लिए खोज करने का नियम। नियमों में, मैं उन चर की शुरूआत की अनुमति देता हूं जो एक नियमित अभिव्यक्ति में निम्नलिखित पैटर्न के अनुरूप हैं:
   
   • {abc} => [A-Za-z] +
   • {123} => [0-9] +
   • {शब्द} => [A-Za-z0-9 _-।] +
   • {lang} => [az] {२}
   • {chars} =>। "
   
   चर में से प्रत्येक को याद किया जाता है और $ 1, $ 2, $ 3 और के रूप में "क्रम" क्षेत्र में प्रतिस्थापित किया जा सकता है जिसमें नियम का पालन किया जाता है।
3. वायरफ्रेम या थीम - सूची का चयन करें। निर्धारित करता है कि इस पृष्ठ पर कौन सी ग्राफिक थीम लागू होगी। यह आमतौर पर डिफ़ॉल्ट वायरफ्रेम है।
4. प्लगइन - सूची का चयन करें। मेरे सिस्टम में, प्लगइन्स MVC संरचनाएं हैं, इसलिए संक्षेप में, यह नियंत्रक का एक संकेत है जो काम पर ले जाएगा।
5. घटना - सूची का चयन करें। नियंत्रक में कहा जाने वाला तरीका।
6. चर - "इनपुट नाम = ________" फॉर्म के कई इनपुट। इस घटना (विधि) में वैध चर। मान्य चर के बारे में जानकारी कॉन्फ़िगरेशन फ़ाइल में संग्रहीत होती है, इसलिए नियम बनाने वाला व्यक्ति मान्य चर के लिए मान निर्दिष्ट कर सकता है।

नतीजतन, हम राउटर के उपयोगकर्ता को केवल निम्नलिखित जिम्मेदारियां सौंपते हैं

• एक अद्वितीय और तार्किक नियम के साथ आओ
• इसे सही ढंग से सूची में रखें ताकि यह दूसरे नियम को ओवरलैप न करे
• चर चर में प्रतिस्थापित करते समय नियम से चर मानों के क्रम को भ्रमित न करें
• अंग्रेजी का ज्ञान (मेरा मानना ​​है कि अब तक का URL अंग्रेजी में होना चाहिए, न कि लिप्यंतरण में और रूसी / अल्बानियाई में नहीं, लेकिन यह विशुद्ध रूप से मेरी राय है)

आपके ध्यान के लिए धन्यवाद, मुझे आशा है कि किसी ने मेरे अनुभव की मदद की, लेकिन कोई व्यक्ति नए विचारों के साथ आया।