वर्तमान डी 8 स्थिति के साथ, "नोड" सामग्री इकाई के लिए एक सामग्री प्रकार बनाने के लिए एक नई सामग्री इकाई प्रकार बनाने के लिए निर्णय पेड़ क्या है?


24

हमने चार साल और द्रुपाल की पहली रिलीज़ को देखा है क्योंकि स्वीकृत उत्तर प्रश्न के लिए लिखा गया था " जब एक एंटिटी बनाम एक नई सामग्री प्रकार जोड़ना उचित है ?" और, ड्रुपल 8 में इकाइयां अधिक केंद्रीय हैं, जितना कि वे ड्रुपल 7 में थे ( RefB , RefC , RefD )

इस नई Drupal 8 दुनिया में, "Node" प्रकार की सामग्री इकाई के लिए एक नई सामग्री प्रकार बनाम एक नई सामग्री प्रकार बनाने के लिए निर्णय वृक्ष क्या है?

जैसा कि आप एक प्रतिक्रिया पर विचार करते हैं, कृपया निम्नलिखित पर विचार करें:

  • क्या "नोड" की सामग्री इकाई प्रकार के लिए एक नई सामग्री प्रकार अभी भी 99% स्थितियों में एक नई सामग्री इकाई प्रकार के लिए उपयुक्त है?
  • क्या निर्णय वृक्ष में अब "नोड" सामग्री इकाई प्रकार का उपयोग करने से दूर करने के लिए अधिक, बेहतर या स्पष्ट कारण शामिल हैं और इसके बजाय एक नई सामग्री इकाई प्रकार बनाते हैं? और यदि हाँ, तो वे क्या हैं? क्या वे शामिल हैं:
    • प्रदर्शन?
    • सुरक्षा / अनुमतियाँ?
    • मॉड्यूल की संख्या जो नोड-इकाई-प्रकार सामग्री-प्रकार के साथ काम करती है और अन्य सामग्री इकाई प्रकारों के साथ काम नहीं करती है?
  • शायद - ऊपर उल्लिखित पिछले स्वीकृत उत्तर के आधार पर - एक कस्टम सामग्री इकाई प्रकार करने का एकमात्र सामान्य कारण यह है कि क्या आप नोड डेटा को समूह में रखना चाहते हैं, जैसे कि वर्गीकरण की शर्तों के साथ, या अन्यथा टिप्पणी के साथ एनोड एनोटेट करें?

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

पाथातो पर एक नज़र डालें, जो वर्तमान में उन लोगों में से चौथा सबसे स्थापित मॉड्यूल है जिनके पास किसी भी प्रकार का 8.x रिलीज़ है। फॉक्स एक 8.x संस्करण पर कड़ी मेहनत कर रहे हैं जो आम तौर पर संस्थाओं का समर्थन करता है और न केवल नोड-इकाई-प्रकार सामग्री प्रकार। लेकिन अन्य सभी मॉड्यूल के बारे में क्या? और क्या मॉड्यूल जो ऐसी संस्थाओं का समर्थन करते हैं, जिन्हें आमतौर पर मॉड्यूल के साथ काम करने से पहले मॉड्यूल-विशिष्ट "हुक" के लिए कस्टम सामग्री इकाई प्रकारों की आवश्यकता होती है? (बनाम कैसे मॉड्यूल नई सामग्री प्रकारों के साथ सीधे बॉक्स से बाहर काम कर सकते हैं?) जो कि pathauto टीम के साथ काम करने की चुनौती के रूप में प्रतीत होता है , और शायद यह एक कस्टम सामग्री इकाई प्रकार से दूर करने का कारण है?

यह भी उल्लेखनीय है कि Drupal 8 कोर में "Node" प्रकार की सामग्री इकाई के लिए नई सामग्री प्रकार बनाने के लिए UI है, लेकिन इसमें वर्तमान में नई सामग्री इकाई प्रकार बनाने के लिए UI नहीं है। ( RefX , RefY , RefZ )

जवाबों:


17

नया नोड-इकाई-प्रकार सामग्री बनाने के बीच चुनने का निर्णय पेड़ बनाम नई सामग्री इकाई प्रकार:

  1. क्या आप एक प्रोग्रामर हैं, या क्या आपके पास प्रोग्रामर की आसान पहुँच है?
    • यदि नहीं, तो आप वर्तमान में नई नोड-इकाई सामग्री प्रकार बनाने के लिए बहुत सीमित हैं। (नई सामग्री इकाई प्रकार बनाने के लिए कोर में UI नहीं है, और एंटिटी कंस्ट्रक्शन किट (ECK) कंट्राब मॉड्यूल वर्तमान में केवल एक अल्फा रिलीज है।)
    • यदि हाँ, तो जारी रखें ...
  2. क्या आप वास्तव में जानते हैं कि आप अपने डेटा के लिए कौन से कंट्रिब्यूल मॉड्यूल का लाभ उठाना चाहते हैं?
    • यदि नहीं, तो सुरक्षित शर्त केवल एक नोड-इकाई सामग्री प्रकार बनाने के लिए है।
    • यदि हाँ, तो क्या वे मॉड्यूल पहले से ही कस्टम इकाई प्रकार (ओं) का समर्थन कर रहे हैं, जिन पर आप विचार कर रहे हैं, या क्या आप उन्हें बढ़ाने में मदद करने के लिए तैयार हैं ताकि वे आपके मॉड्यूल में वांछित कार्यक्षमता को बनाएंगे या फिर से बनाएंगे?
      • यदि नहीं, तो केवल एक नोड-इकाई-प्रकार की सामग्री बनाना आपके लिए सबसे अच्छा हो सकता है।
      • यदि हाँ, तो जारी रखें ...
  3. क्या आपके मॉड्यूल द्वारा सक्षम वास्तविक सामग्री डेटा केवल समूह या अन्य सामग्री डेटा को एनोटेट करने में मदद करेगा? (ताकि इसे शायद ही कभी देखा जा सके।)
    • यदि हाँ, तो इस बात पर विचार करें कि क्या आपका मॉड्यूल मौजूदा इकाई प्रकारों के लिए है जैसे कि वर्गीकरण की शर्तें और टिप्पणियां यदि यह है, तो एक नया निकाय प्रकार एक सुरक्षित शर्त हो सकता है।
    • यदि नहीं, तो जारी रखें ...
  4. क्या आप स्पष्ट रूप से स्पष्ट कर सकते हैं कि एक नया नोड-इकाई-प्रकार सामग्री प्रकार आपके लिए काम क्यों नहीं करेगा?
    • यदि नहीं, तो आपका सुरक्षित दांव केवल एक नया नोड-इकाई-प्रकार सामग्री प्रकार बनाना है।
    • यदि हाँ, तो जारी रखें ...
  5. अंत में, क्या आप सुनिश्चित हैं कि आप केवल नोड-इकाई-प्रकार का विस्तार नहीं कर सकते हैं और आप CRUD संचालन जैसी इसकी सभी उपयोगी कार्यक्षमता को फिर से बनाना चाहते हैं?
    • यदि हाँ, तो आगे बढ़ें और एक नया कस्टम इकाई प्रकार बनाएँ।
    • यदि नहीं, या यदि आप निश्चित नहीं हैं, तो आप संभवतः कुछ विशेषज्ञों को आपके निर्णय लेने में मदद करने के लिए संलग्न करना चाहते हैं।

टिप्पणियाँ:

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

1
दिलचस्प सवाल है, और प्रभावशाली जवाब, चापू! (ओप्स: हैट्स ऑफ!)। आपके नोट (1) में "सुरक्षा" भाग के बारे में: समूह (= डी 8 के लिए "ओग" का एक रूपांतर) उस पर विचार करने के लिए योग्य हैं?
पियरे.व्रीन्स

@ पियरे.व्रीन्स, मर्सी बीकूप्प! नोट (1) के "सुरक्षा" भाग को एक पोस्ट द्वारा कहीं से संकेत दिया गया था (मुझे याद नहीं है कि कहां है) कि नई इकाई प्रकारों के बजाय बहुत सी नई सामग्री प्रकार बनाने से संभावना बढ़ जाती है कि आप गलती से किसी विशेष सामग्री प्रकार का खुलासा कर सकते हैं डेटा। समूह के संदर्भ के लिए धन्यवाद। यह निश्चित रूप से सुरक्षा कार्यक्षमता के लिए एक तैयार-निर्मित विकल्प प्रदान करके नई संस्थाओं के निर्माण की सुविधा प्रदान करता है जो केवल नोड सामग्री प्रकारों के लिए हो सकते हैं। इसलिए, यह स्वयं सुरक्षा कार्यक्षमता बनाने के लिए इकाई प्रकार डेवलपर्स की आवश्यकता को समाप्त कर सकता है।
जॉन फ्रीड

3

उस मुद्दे के बारे में एक सरल दृष्टिकोण परियोजना के उद्देश्य, आकार और व्यावसायिक आवश्यकताओं को ध्यान में रखना है।

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

यहाँ एक महत्वपूर्ण सूचना यह है कि नई इकाई प्रकार बनाने का निर्णय आमतौर पर डेवलपर्स या तकनीकी लीड लेता है जो साइट बिल्डरों या प्रोजेक्ट मालिकों को नहीं होता है जो एप्लिकेशन का प्रबंधन करते हैं और केवल व्यवसाय पर ध्यान केंद्रित करते हैं।

  1. Drupal 8 कुछ सिम्फनी 2 पैकेजों पर निर्भर करता है और फ्रेमवर्क के अधिक करीब है, विकास जो कि उस बड़े वास्तु परिवर्तन के साथ Drupal के बारे में बात कर रहा है, मैं कल्पना करता हूं कि एक नई इकाई का निर्माण नोड-इकाई सामग्री प्रकारों में कई अनुकूलन और जटिल कॉन्फ़िगरेशन करने से बेहतर है Drupal को अन्य चौखटों के बीच ले जाने के लिए, क्योंकि बहुत से लोग Drupal कॉन्फ़िगरेशन और वितरित सेटिंग्स से प्यार नहीं करते हैं, आप कुछ लोगों का सामना वर्डप्रेस से कर सकते हैं और प्रत्येक चीज़ को एक फ़ॉर्म से कॉन्फ़िगर करने के लिए उपयोग करते हैं, जो Drupal admin डैशबोर्ड के साथ काम करते समय उन्हें परेशान करता है।

  2. Drupal 9 की योजना पूरी तरह से हुक सिस्टम को हटाने और ईवेंट डिस्पैचर के साथ बदलने की है जो एक नई इकाई बनाने के लिए एक व्यवस्थापक इंटरफ़ेस की बड़ी आवश्यकता की ओर जाता है क्योंकि कोड से मौजूदा कार्यक्षमता को बदलना उन लोगों के लिए बहुत कठिन होगा जो डेवलपर्स नहीं हैं और बहुत आवश्यक होंगे उस सुविधा को जोड़ें।

अंत में , मुझे लगता है कि परियोजना की जरूरतों के अनुरूप नई इकाइयाँ बड़ी संख्या में क्षेत्रों के साथ जटिल सामग्री प्रकारों की तुलना में बेहतर प्रदर्शन देती हैं क्योंकि अब हम प्रत्येक क्षेत्र डीबी में 2 तालिकाओं को जोड़ते हैं और प्रत्येक अनुरोध पर विशेष रूप से इसके कॉन्फ़िगरेशन को लोड करने की आवश्यकता होती है। भारी व्यापार तर्क की आवश्यकता है।


3

सादा और सरल: यह सभी सामग्री नहीं है। यदि आप केवल सामग्री प्रकार का उपयोग कर रहे हैं तो सामग्री की सूची काफी लंबी हो सकती है और भ्रमित हो सकती है। ( ContentEntityBase भी एक कस्टम इकाई Thoe द्वारा कार्यान्वित किया जा सकता है)

यदि आपके पास एक लेखक और प्रकाशित राज्य है, तो आपको एक सामग्री प्रकार के लिए जाना चाहिए।


अन्यथा (अपने प्रोग्रामर को मानते हुए) कस्टम संस्थाओं को प्राथमिकता दी जानी चाहिए। सभी इंटरफेस (जैसे संशोधन-सक्षम, क्षेत्र-सक्षम, पहुंच प्रतिबंध आदि) के साथ बहुत आसानी से लागू किया जा सकता है।

मेरे विचार में यह सिर्फ स्पष्ट और पूंछ-निर्मित वास्तुकला है (और अधिक प्रदर्शन करने वाला भी)।

कई परियोजनाओं में पुन: प्रयोज्यता के बारे में सोचकर कस्टम संस्थाओं को उड़ाने का प्रयास किया जाता है .. जिसमें ड्रूपल-कोड-जनरेटर जैसे निफ्टी हेल्पर्स भी हैं । निम्न स्तर पर कस्टम कोडिंग (या जटिलता) रखने के लिए, यदि आप चाहें तो सामग्री प्रकारों का उपयोग करने पर विचार करें:

  • 'इकाई' (कम से कम D7 में) का अनुवाद करने के लिए, एक इंटरफ़ेस भी होगा।
  • (सुझावों के लिए खुला) ।।

3

यह एक कठिन सवाल है कि ईमानदारी से मुझे लगता है कि केवल एक बार समझा जाता है कि आपने इसे पहले लागू किया है। लेकिन रेमी के रूप में, सब कुछ कच्चा नहीं है, उपयोगकर्ता सामग्री का सामना कर रहा है

Drupal 7 में, कस्टम इकाइयाँ बनाने की क्षमता मौजूद थी, लेकिन यदि आप OOP के साथ किनारों के आसपास मोटे थे, तो यह एक कठिन काम हो सकता है। यह आधे तरह से लागू किया गया था (या आधा किया गया था, हालांकि आप इसे कहना चाहते हैं), जो उन संस्थाओं को बनाने के तरीके की ओर जाता है जो बिल्कुल समान नहीं थे और दृष्टिकोण पर सहमत थे, मिश्रित प्रक्रियात्मक और मिश्रित ओओपी के साथ।

Drupal 8 में, विचार बहुत अधिक साकार है, और कस्टम इकाई के साथ उठना और चलना बहुत आसान है। नोड स्वयं ContentEntityBase पर आधारित है, जैसे कि ब्लॉक, उपयोगकर्ता, फ़ाइल, और वर्गीकरण।

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

आदर्श सामग्री जो महान सामग्री प्रकार बनाती है:

  • लेख
  • पृष्ठ
  • नौकरी की पोस्टिंग
  • घटना
  • लैंडिंग पृष्ठ
  • मुखपृष्ठ

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

लेकिन मान लें कि आप Drupal में डेटा स्टोर करना चाहते हैं जो आंतरिक, निजी है, अन्य डेटा ड्राइव करता है, या डेटा जो इसके दायरे से बाहर एकीकरण की अनुमति नहीं देता है जब तक कि आप इसे अनुमति नहीं देते हैं। यह किस तरह का डेटा हो सकता है? यहाँ कुछ संभावित प्रकार हैं:

  • उत्पाद (ड्रुपल कॉमर्स)
  • लाइन आइटम (Drupal वाणिज्य)
  • खोज सर्वर (ApacheSolr / SearchAPI)
  • संपर्क (जैसे CRM लीड)
  • टिकट (समर्थन टिकट की तरह)

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

यहाँ से, यह काफी हद तक Drupal / Node सिस्टम के अधिक स्वचालित भागों से तलाकशुदा है और आप कार्यों और अनुभव को दर्जी कर सकते हैं। आप रूट, पहुंच और CRUD वर्कफ़्लो निर्धारित करते हैं।

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

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

इस तरह का डेटा आमतौर पर विशिष्ट होता है और इसके लिए नियंत्रण की आवश्यकता होती है कि नोड किसके लिए है। यह कहना नहीं है कि आप डेटा को समृद्ध करने के लिए नोड पर एक संदर्भ क्षेत्र का उपयोग करके अपनी कस्टम इकाई को इंगित करने का उपयोग करके इसे बढ़ा नहीं सकते हैं (यह ड्रुपल कॉमर्स ने किस स्तर पर काम किया है)। उसी समय, आप अलग-अलग कंट्रास्ट कोड से अपने डेटा और UI पर नियंत्रण को अलग कर रहे हैं और सुनिश्चित कर रहे हैं कि यह डिज़ाइन से परे है और आपके मॉडल के साथ हस्तक्षेप कर रहा है। यह डी 8 की तुलना में डी 8 में एक समस्या की संभावना कम है, हालांकि कुछ हुक बने हुए हैं।

उचित वास्तुकला अब अलगाव को प्रोत्साहित करने के लिए मौजूद है। सब कुछ एक नोड नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.