नए एंटिटी कॉन्सेप्ट के साथ ड्रुपल 7 के लिए विकास

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

क्या खाने के साथ है?

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

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

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

ऐसा लगता है कि सब कुछ ठीक है, लेकिन एक समस्या बनी हुई है। जैसा कि पहले उल्लेख किया गया है, नोड प्रकार के माध्यम से एक कार्यान्वयन में कुछ सीमाएं हैं, जो कुछ मामलों में, इस दृष्टिकोण को असुविधाजनक या असंभव बनाते हैं। विशेष रूप से, यह कल्पना करना कठिन है कि Drupal 6 में उपयोगकर्ता या टिप्पणियां सामग्री प्रकारों के रूप में कार्यान्वित की जाती हैं। बेशक, उपयोगकर्ताओं को सामग्री के प्रकारों के रूप में लागू करने की संभावना या असंभवता के विषय पर यहां मनमाने ढंग से लंबी बहस होती है, लेकिन किसी भी मामले में इस दृष्टिकोण को सुरुचिपूर्ण और सही नहीं कहा जा सकता है।

ड्रुपल 7 के आगमन के साथ क्या बदल गया है? वास्तव में, अमूर्तता का एक नया स्तर बनाया गया है। और उसका नाम एंटिटी है। वास्तव में, Entity, Drupal 6 में नोड की तुलना में निम्न स्तर का है। मैं तुरंत एक आरक्षण करता हूँ कि Drupal 7 में नोड्स गायब नहीं हुए हैं, हालाँकि, अब वे Entity के लिए एक ऐड-ऑन हैं। सबसे अच्छी बात यह है कि Drupal 7 में उपयोगकर्ता, टिप्पणियां और बहुत कुछ भी एंटिटी हैं। आप पहले से ही "बॉक्स से बाहर" अंतर महसूस कर सकते हैं। उदाहरण के लिए, पहले, CCK मॉड्यूल का उपयोग करके, आप केवल सामग्री प्रकारों में नए फ़ील्ड जोड़ सकते हैं। Drupal 7 में, आप उपयोगकर्ताओं, टिप्पणियों, और यहां तक ​​कि टैक्सोनॉमी टैग के साथ भी ऐसा कर सकते हैं। ऐसा इसलिए है क्योंकि टैग, सामग्री, टिप्पणियां और उपयोगकर्ता इकाई के सभी उपवर्ग हैं।

एक शव परीक्षा दिखाएगा

एक इकाई प्रणाली की आंतरिक संरचना पर एक चर्चा शुरू करने से पहले, यह api.drupal.org जैसे अद्भुत संसाधन को याद करने के लायक है, जहां आप शेक्सपियर भाषा में बाद में चर्चा किए गए सभी इंटरफेस, कक्षाओं और तरीकों से खुद को परिचित कर सकते हैं।

इसलिए, यह देखने का समय है कि यह सब कैसे काम करता है। इस तथ्य के बावजूद कि ड्रुपल 7 में (जैसा कि बाद में देखा जाएगा), ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग बहुत अधिक सक्रिय रूप से उपयोग हो गया है, इस प्रणाली को सूचित करने के लिए कि हमारा मॉड्यूल एक नई इकाई को लागू करता है, हमें एक हुक लागू करना होगा। जिस हुक में हम रुचि रखते हैं वह है हुक_एंटिटी_इनफो () । इसमें से हमें एक साहचर्य सरणी वापस करनी चाहिए, जिसकी कुंजी उन संस्थाओं के नाम होंगे जिन्हें हम लागू करेंगे। बदले में, प्रत्येक इकाई अपने मापदंडों की एक सरणी के अनुरूप होगी। नीचे उन मापदंडों की एक सूची दी गई है जिन्हें हम निर्दिष्ट कर सकते हैं:

• लेबल: तथाकथित "मानव-पठनीय" प्रकार हमारी इकाई का नाम। यदि आप लेबल को अनुवाद योग्य बनाना चाहते हैं तो टी () में लपेटा जाना चाहिए।
• कंट्रोलर क्लास: काउंटरऑलर क्लास का नाम जो डेटा लोड करने के लिए जिम्मेदार होगा। क्लास को DrupalEntityControllerInterface इंटरफ़ेस लागू करना होगा। यदि आप इस पैरामीटर को निर्दिष्ट नहीं करते हैं, तो डिफ़ॉल्ट नियंत्रक, DrupalDefaultEntityController, नियंत्रक के रूप में इस्तेमाल किया जाएगा (इस लेख में बाद में इकाई नियंत्रकों पर चर्चा की जाएगी)।
• आधार तालिका: हमारी इकाई के लिए डेटाबेस में आधार तालिका। औपचारिक रूप से, पैरामीटर वैकल्पिक है, क्योंकि DrupalDefaultEntityController वर्ग से विरासत में मिला है। यानी आप DrupalEntityControllerInterface इंटरफ़ेस को अपने तरीके से लागू कर सकते हैं और डेटाबेस तालिका से डेटा प्राप्त नहीं कर सकते, लेकिन कम से कम मंगल ग्रह के उपग्रह से, लेकिन यदि आपने DrupalDefaultEntityController या नियंत्रक के रूप में इसके व्युत्पन्न का उपयोग करने का निर्णय लिया है, तो कृपया इस पैरामीटर को निर्दिष्ट करें। आगे देखते हुए, मैं कहता हूँ कि ज्यादातर मामलों में नियंत्रक DrupalDefaultEntityController से या यहां तक ​​कि उच्च-स्तरीय वर्ग, जैसे कि EntityAPIController (बाद में चर्चा करने के लिए) से विरासत में आता है।
• संशोधन तालिका: पिछले के समान, लेकिन इस मामले में संशोधन तालिका। नोड्स के साथ एक सादृश्य यहाँ ठीक पता लगाया गया है। यदि आपकी इकाई विभिन्न संशोधन नहीं मानती है, तो पैरामीटर को छोड़ा जा सकता है।
• स्थिर कैश: DrupalDefaultEntityController द्वारा उपयोग किया जाने वाला एक और पैरामीटर। पृष्ठ अनुरोध के दौरान स्थैतिक निकाय कैशिंग को सक्षम करता है। यानी इस मामले में, यह अनुरोधों के बीच कैशिंग के बारे में नहीं है (जब डेटा एक निश्चित अवधि के लिए कैश किया जाता है और कैश से समाप्त होने तक प्रत्येक नए अनुरोध के साथ कैश से वापस आ जाता है), लेकिन एक अनुरोध के लिए कैशिंग के बारे में। इस प्रकार, यदि यह क्वेरी पथ के सार को बदलने और फिर इसे लोड करने की योजना नहीं है, तो इसे TRUE पर सेट करने के लिए समझ में आता है (या बस पैरामीटर को छोड़ दें, क्योंकि डिफ़ॉल्ट रूप से यह TRUE है)।
• फ़ील्ड कैश: यहां हम फील्ड्स (फील्ड एपीआई) के संबंध में लगातार कैश के बारे में बात कर रहे हैं, जो बाद में दिखाया जाएगा, संस्थाओं से जुड़ा जा सकता है। आधिकारिक दस्तावेज में कहा गया है कि इस पैरामीटर को FALSE में सेट करना तभी समझ में आता है जब पूरी इकाई निरंतर कैशिंग के अधीन हो। दूसरे शब्दों में, यदि आपको ठीक-ठीक पता नहीं है कि आपको इसकी आवश्यकता क्यों है, तो इस पैरामीटर को छोड़ना बेहतर है और याद रखें कि डिफ़ॉल्ट रूप से यह TRUE पर सेट है।
• लोड हुक: DrupalDefaultEntityController में प्रयुक्त एक और पैरामीटर। DrupalDefaultEntityController द्वारा कहा जाता है: संलग्नक फ़ंक्शन और अन्य मॉड्यूल को इकाई को अपनी जानकारी संलग्न करने की अनुमति देता है। किसी भी स्थिति में, अटैच_लोड फ़ंक्शन सभी संस्थाओं के लिए हुक_ओनिटी_लोड कहेगा, जबकि निर्दिष्ट लोड हुक आपको अपनी इकाई के लिए एक अलग हुक कॉल करने की अनुमति देगा (जैसे नोड मॉड्यूल में हुक_नोड_लोड)।
• uri callback: इकाई को एक तर्क के रूप में लिया जाता है। इकाई घटकों (जैसे पथ और विकल्प) के यूरी को लौटाता है जिससे इकाई का पता बाद में यूरी () फ़ंक्शन का उपयोग करके प्राप्त किया जा सकता है। इस फ़ंक्शन की परिभाषा के लिए अलग-अलग दृष्टिकोण हैं। एंटिटी एपीआई मॉड्यूल में, विशेष रूप से, एक इकाई_क्लास_यूरी फ़ंक्शन होता है जो बस $ एंटिटी को बुलाता है-> यूरी () फ़ंक्शन ने इसे पारित किया, इस प्रकार यह इकाई को अपना पता निर्धारित करने की क्षमता प्रदान करता है।
• लेबल कॉलबैक: इकाई का नाम पाने के लिए उपयोग किया जाने वाला एक वैकल्पिक पैरामीटर। तर्कों के रूप में, यह अपने आप में और इकाई के प्रकार को लेता है। यदि इकाई का नाम इस इकाई के कुछ मापदंडों (जैसे नोड का नाम शीर्षक फ़ील्ड के बराबर है) के बराबर है, तो 'लेबल' का उपयोग करना बेहतर है - तत्व 'इकाई कुंजी' (बाद में वर्णित किया जाएगा)। यदि नाम किसी तरह से एक विशेष तरीके से बनता है (उदाहरण के लिए, कुछ क्षेत्रों के संयोजन के रूप में), तो आप इसे 'लेबलबैक' का उपयोग करके सेट कर सकते हैं।
• फ़ील्डेबल: जैसा कि कहा जाता है "और यह मैजिक है"। TRUE पर सेट करके और यह मानकर कि आपका नियंत्रक इस कार्यक्षमता को लागू करता है (या DrupalDefaultEntityController से विरासत में मिला है), आप Drupal Field API (Drupal 7 में Drupal 6 का CCK एनालॉग कर्नेल में एकीकृत है) का उपयोग करके अपनी इकाई को एक्स्टेंसिबल बनाते हैं। यानी उपयोगकर्ताओं के साथ, नोड्स के प्रकार, टैग और बहुत कुछ, विभिन्न क्षेत्रों को आपकी इकाई से जोड़ा जा सकता है।
• अनुवाद: विवरण में जाने के बिना - यह क्षेत्र आपकी इकाई और इससे जुड़े क्षेत्रों को अनुवाद योग्य बनाना संभव बनाता है। यदि रिक्त नहीं है, तो एक साहचर्य सरणी को मूल्य के रूप में इंगित किया जाता है, जहां चाबियाँ मॉड्यूल के नाम हैं जो अनुवाद करने की क्षमता प्रदान करते हैं, और मान अनुवाद के लिए आवश्यक किसी भी प्रकार की सूचना संरचनाएं हैं।
• इकाई कुंजी: फ़ील्ड एपीआई द्वारा उपयोग किया जाने वाला पैरामीटर। एक साहचर्य सरणी जिसमें निम्नलिखित तत्व शामिल हो सकते हैं:
• - आईडी: एक इकाई क्षेत्र जिसमें एक इकाई के लिए एक विशिष्ट प्राथमिक पहचानकर्ता होता है। यदि फ़ील्ड को TRUE पर सेट किया गया है, तो आवश्यक है। मान एक धनात्मक पूर्णांक होना चाहिए।
• - संशोधन: पैरामीटर का नाम जिसमें संशोधन आईडी है। फ़ील्ड एपीआई मानता है कि एक प्रकार के भीतर सभी संस्थाओं में एक अद्वितीय संशोधन आईडी है। यदि आपकी इकाई संस्करण (संशोधन) मॉडल को लागू नहीं करती है, तो पैरामीटर छोड़ा जा सकता है।
• - बंडल: वह पैरामीटर जो इंगित करता है कि इकाई किस बंडल (उपप्रकार) से संबंधित है। प्रत्येक बंडल के पास खेतों का अपना सेट है। यहां, एक अच्छा उदाहरण नोड्स के प्रकार होंगे, जहां प्रत्येक प्रकार के लिए आप अपने स्वयं के फ़ील्ड निर्दिष्ट कर सकते हैं (इस तथ्य के बावजूद कि अंत में, सभी प्रकार एक इकाई हैं)। यदि आप अपने इकाई प्रकार में ऐसी सुविधाओं को लागू नहीं करने जा रहे हैं (उनके लिए अलग बंडल और फ़ील्ड के अलग-अलग सेट होने की योजना नहीं है), तो आप इस पैरामीटर को छोड़ सकते हैं। फिर, इकाई प्रकार का नाम स्वचालित रूप से एक पैरामीटर के रूप में उपयोग किया जाएगा।
• - लेबल: एक पैरामीटर जो इकाई के नाम को इंगित करता है। यदि शीर्षक गतिशील रूप से बनना चाहिए, तो पहले वर्णित लेबल कॉलबैक पैरामीटर का उपयोग करें।
• बंडलों: वास्तव में हमारी इकाई के प्रकार के बंडलों (उपप्रकार) के एक सेट को परिभाषित करता है। कुंजियों का एक सहयोगी सरणी जो बंडलों के मशीन नाम हैं (उस रूप में जिसमें वे 'इकाई कुंजी' पैरामीटर में परिभाषित 'बंडल' फ़ील्ड में संग्रहीत किए जाते हैं)। बंडलों के नाम, बदले में, निम्नलिखित कुंजियों के साथ सहयोगी सरणियों से जुड़े हैं:
• - लेबल: "मानव-पठनीय" बंडल का नाम है। हमेशा की तरह, हम टी () में लपेटते हैं यदि हम चाहते हैं कि नाम अनुवाद योग्य हो।
• - uri callback: इकाई प्रकार के लिए 'uri callback' के रूप में ही, केवल बंडल के लिए। यदि ये दोनों निर्दिष्ट हैं, तो बंडल के लिए कॉलबैक का उपयोग किया जाएगा।
• - व्यवस्थापक: जानकारी के साथ एक सरणी जो फ़ील्ड API को इकाई प्रशासन पृष्ठों में अपने पृष्ठों को एम्बेड करने की अनुमति देगा।
• - पथ: बंडल प्रशासन पृष्ठ का पथ। यदि पथ में एक प्लेसहोल्डर शामिल है, तो आपको 'बंडल तर्क' और 'वास्तविक पथ' (नीचे चर्चा की गई) के लिए मान निर्दिष्ट करने की आवश्यकता होगी।
• - - बंडल तर्क: पथ में स्टब की स्थिति। सिद्धांत वही है जब मेनू पथ के साथ काम कर रहा है।
• - - वास्तविक पथ: स्टब के बिना बंडल प्रशासन पृष्ठ का पथ। लिंक उत्पन्न करने के लिए उपयोग किया जाएगा।
• - - एक्सेस कॉलबैक: हुक_मेनू () के समान। यदि खाली छोड़ दिया जाता है, तो user_access () का उपयोग किया जाएगा।
• - - पहुंच तर्क: हुक_मेनू में () के समान।
• व्यू मोड: इकाई प्रदर्शित करने के विभिन्न तरीके (प्रकार)। एक अच्छा उदाहरण भरा हुआ है और नोड में टीज़र है। एक साहचर्य सरणी जिसमें मशीन दृश्य नाम कुंजी के रूप में उपयोग किए जाते हैं। डिफ़ॉल्ट रूप से, प्रत्येक इकाई में एक डिफ़ॉल्ट दृश्य होता है। अन्य सभी दृश्य डिफ़ॉल्ट मानों को इनहेरिट कर सकते हैं यदि TRUE दृश्य मापदंडों की 'कस्टम सेटिंग्स' पर सेट है। प्रत्येक दृश्य निम्नलिखित कुंजियों के साथ एक सरणी है:
• - लेबल: "मानव-पठनीय" दृश्य नाम। हमेशा की तरह, हम टी () में लपेटते हैं यदि हम चाहते हैं कि नाम अनुवाद योग्य हो।
• - कस्टम सेटिंग्स: सख्ती से बोलते हुए, यह विकल्प मुख्य रूप से फ़ील्ड पर लागू होता है। यदि FALSE (डिफ़ॉल्ट मान) पर सेट किया गया है, तो प्रारंभ में दृश्य डिफ़ॉल्ट दृश्य से फ़ील्ड प्रदर्शित करने के लिए सेटिंग्स इनहेरिट करेगा। फिर फ़ील्ड UI के माध्यम से सेटिंग्स को बदला जा सकता है।

यह वास्तव में सभी प्रकार है जो इकाई प्रकार के लिए निर्दिष्ट किया जा सकता है। यह ध्यान दिया जाना चाहिए कि DrupalDefaultEntityController के लिए ऐड-ऑन, उदाहरण के लिए, EntityAPIController, के लिए अतिरिक्त मापदंडों का उपयोग करने की आवश्यकता हो सकती है। उदाहरण के लिए एक EntityAPIController 'एंटिटी क्लास' पैरामीटर का उपयोग करता है। इस संभावना को फ़ंक्शन एंटिटी_गेट_इनफो ($ एंट्री_टाइप = NULL) के लिए धन्यवाद प्राप्त होता है, जो आपको वांछित प्रकार की इकाई के बारे में डेटा प्राप्त करने की अनुमति देता है।

इकाई नियंत्रक

अब आइए इकाई नियंत्रक पर ध्यान केन्द्रित करें, जिसे 'नियंत्रक वर्ग' पैरामीटर में परिभाषित किया गया है। वास्तव में, एक नियंत्रक आपकी इकाई के डेटा को प्रबंधित करने का एक तरीका है। ओओपी के बारे में मुझे जो पसंद है वह यह है कि यह न केवल कोड को अधिक कुशल बनाता है, बल्कि इसके अंदर की प्रक्रियाओं को समझना भी आसान बनाता है। यह समझने के लिए कि नियंत्रक कैसे काम करता है, हम नीचे से समीक्षा शुरू करते हैं। परिभाषा के अनुसार, DrupalEntityControllerInterface इंटरफ़ेस को लागू करने वाले पैरामीटर को 'नियंत्रक वर्ग' पैरामीटर में निर्दिष्ट किया जाना चाहिए। और संस्थाओं की अवधारणा की स्पष्ट जटिलता के बावजूद, यह इंटरफ़ेस आश्चर्यजनक रूप से न्यूनतर है। यह केवल तीन विधियों के कार्यान्वयन के हमारे वर्ग में उपस्थिति को मानता है:
DrupalEntityControllerInterface :: लोड - एक या अधिक संस्थाओं को लोड करता है। पहले तर्क के रूप में लोड करने के लिए इकाई आईडी की एक सरणी होती है। दूसरे तर्क के रूप में, यह 'फ़ील्ड' => 'मान' के रूप में शर्तों की एक निश्चित सरणी लेता है।
DrupalEntityControllerInterface :: resetCache - clears (flushes) सभी संस्थाओं के लिए स्थिर कैश (यदि कोई तर्क निर्दिष्ट नहीं है) या संस्थाओं के चयनित सेट के लिए (यदि संबंधित आईडी सरणी को तर्क के रूप में पारित किया जाता है)
DrupalEntityControllerInterface :: __ निर्माण - निर्माता। एकल तर्क के रूप में, उस इकाई के प्रकार को स्वीकार करता है जिसके लिए नियंत्रक का एक उदाहरण बनाना है। इस प्रकार, जिस प्रकार की इकाई के लिए नियंत्रक बनाया जा रहा है, उसे जानने के बाद, कोई भी इस प्रकार के मापदंडों को प्राप्त कर सकता है, जो कि unit_get_info ($ unit_type) का उपयोग करके और नियंत्रक के बनाए गए उदाहरण को अनुकूलित कर सकता है।

यह वास्तव में वे सभी विधियाँ हैं जिन्हें आपकी कक्षा में लागू किया जाना चाहिए ताकि इसे इकाई नियंत्रक कहलाने का पूरा अधिकार हो। हालांकि, ज्यादातर मामलों में यह इंटरफ़ेस को खरोंच से लागू नहीं करने के लिए समझ में आता है, लेकिन DrupalDefaultEntityController वर्ग से अपने नियंत्रक वर्ग को प्राप्त करने के लिए , जिसे हम अब जांचेंगे ।
DrupalDefaultEntityController हमें क्या देता है?

1. 'बेस टेबल' के मापदंडों में निर्दिष्ट डेटाबेस टेबल्स के प्रकार और यूनिट प्रकार के 'रिवीजन टेबल' की परवाह किए बिना किसी भी संस्था को लोड करने की क्षमता।
2. फ़ील्ड API का उपयोग करते हुए फ़ील्ड एंट्री के लिए TRUE पर सेट होने पर फ़ील्ड API का उपयोग करके हमारी इकाई में फ़ील्ड्स अटैच किए जाते हैं।
3. कुशलता से संस्थाओं को लोड करने की क्षमता। वर्ग स्थिर कैशिंग का समर्थन करता है। (हालांकि, संक्षेप में, DrupalEntityControllerInterface इंटरफ़ेस के रीसेटकैच विधि संकेत देता है कि किसी भी इकाई नियंत्रक में स्थिर कैशिंग लागू किया जाना चाहिए)।

इस प्रकार, DrupalDefaultEntityController अपने लक्ष्य के रूप में अंत उपयोगकर्ता के लिए कार्यक्षमता के कार्यान्वयन के रूप में सेट नहीं करता है, यह केवल डेवलपर के लिए कुछ शुरुआती बिंदु प्रदान करता है। इसके अलावा, ऐसे मामलों में जहां आपकी इकाई को किसी तरह CRUD (क्रिएट रीड अपडेट डिलीट) कॉन्सेप्ट को लागू करना होगा, यह आपके नियंत्रक को एक उच्चतर स्तर के वर्ग - EntityAPIController, जो कि Entity API मॉड्यूल में प्रस्तुत किया जाता है, से समझ में आता है। हालांकि, एंटिटी एपीआई के साथ काम करने के सिद्धांतों पर विचार करना इस लेख के दायरे से परे है और एक और समय समर्पित होगा।