पॉलिमॉर्फिक एसोसिएशन और रूबी ऑन रेल्स में डेविस

सभी को नमस्कार।
एक बार जब मैंने रूबी ऑन रेल्स में बहुरूपी संघों के बारे में एक लेख लिखा था और मुझे याद है, कुछ अशिष्ट थे: क्यों, वे कहते हैं, रेल 2 के बारे में लिखें, अगर नया संस्करण आ रहा है।

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

कार्य निम्नानुसार था: दो प्रकार के उपयोगकर्ता हैं, पंजीकरण और लॉगिन एक रूप से किया जाना चाहिए, पंजीकरण के दौरान उपयोगकर्ता इंगित करता है कि वह कौन होना चाहता है: ग्राहक या ठेकेदार।
तदनुसार, उपयोगकर्ताओं की परियोजना में अलग-अलग भूमिकाएँ थीं, वे अलग-अलग काम कर सकते थे।

इस प्रकार, मानक डेविस प्रलेखन के अनुसार, मैंने इसे परियोजना में जोड़ा। डेविस ने जो माइग्रेशन बनाया, उसमें मैंने निम्नलिखित फ़ील्ड्स जोड़े:

t. string :name, : null => false t.references :character, :polymorphic => true * This source code was highlighted with Source Code Highlighter .

1. t. string :name, : null => false t.references :character, :polymorphic => true * This source code was highlighted with Source Code Highlighter .
2. t. string :name, : null => false t.references :character, :polymorphic => true * This source code was highlighted with Source Code Highlighter .

t. string :name, : null => false t.references :character, :polymorphic => true * This source code was highlighted with Source Code Highlighter .

नाम के अलावा, यहां आप सभी प्रकार के उपयोगकर्ताओं के किसी भी अन्य सामान्य गुण बना सकते हैं: देश, पता, आदि। इस क्षेत्र में मेरा केवल एक नाम था।
दस्तावेज़ के अनुसार दूसरी पंक्ति, (http://apidock.com/rails/ActiveRecord/ConnectionAdapters/Table/references), हमारे लिए दो फ़ील्ड बनाएगी: character_id और character_type: पहला "चरित्र" का आईडी होगा, और दूसरा वर्ग का नाम होगा। जहां इस आईडी के लिए देखने के लिए।

उसके बाद, रेक डीबी चलाएं: माइग्रेट करें, और फिर user.rb मॉडल जोड़ें।

1. वर्ग उपयोगकर्ता <ActiveRecord :: बेस
2. # डिफ़ॉल्ट डेविस मॉड्यूल शामिल करें। अन्य उपलब्ध हैं:
3. #: token_authenticatable ,: एन्क्रिप्ट करने योग्य, पुष्टिकारक: लॉक करने योग्य, समय से हटाने योग्य, ट्रैक करने योग्य और: omniauthable
4. devise: database_authenticatable ,: रजिस्टर करने योग्य, पुनर्प्राप्त करने योग्य, याद रखने योग्य,: मान्य
6. # अपने मॉडल के लिए सुलभ (या संरक्षित ) विशेषताओं को सेटअप करें
7. attr_accessible: name ,: email ,: password ,: याद_मे ,: character_id ,: character_type ,: character ,: character_attributes
9. # मान्यताओं
10. validates_presence_of: नाम ,: character_type
11. validates_inclusion_of: character_type ,: in =>% w (ग्राहक कार्यकारी)
13. # संघों
14. अंतर्गत_तो: चरित्र,: बहुरूपी => सत्य :: आश्रित =>: नष्ट
16. # नेस्टेड विशेषताएँ
17. स्वीकारें_न्यायाचित_पत्रिकाएँ_रूप: वर्ण
19. # प्राधिकरण सहायक विधियाँ
20. ग्राहक को हराया
21. character_type == "ग्राहक"
22. अंत
24. कार्यपालिका को हराया?
25. character_type == "कार्यकारी"
26. अंत
27. अंत

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

यहाँ हमने attr_accessible, जोड़े गए सत्यापन, पंजीकृत संघों को जोड़ा और स्वीकार किए जाते हैं स्वीकार किए गए_nested_attributor_for में नए फ़ील्ड जोड़े।
Attr_accessible में परिवर्तन की आवश्यकता है ताकि आप एक समय में एक के बजाय डेटा को बैचों में सहेज सकें।
मान्यताओं को यह सुनिश्चित करने की आवश्यकता है कि जिन अभिलेखों की हमें आवश्यकता है उन्हें जोड़ा गया है (और उनका प्रारूप भी हमें सूट करता है)।
काकबे बहुरूपी एसोसिएशन हमें संकेत देता है कि उपयोगकर्ता के पास अब एक चरित्र क्षेत्र है जो ग्राहक या कलाकार को संदर्भित करता है। वास्तव में, यह हमारे उपयोगकर्ता मॉडल के लिए एक अतिरिक्त है, जो एक प्रकार का या किसी अन्य का हो सकता है।
assepts_nested_attributes_for की आवश्यकता है ताकि आप नेस्टेड फॉर्म बना सकें (उपयोगकर्ता के लिए एक ऐसा रूप जिसमें चरित्र के लिए सबफॉर्म एम्बेडेड है (अर्थात, ग्राहक के लिए या कलाकार के लिए)।
अंत में दो विधियां सिर्फ सुविधा के लिए हैं, ताकि आप आसानी से और जल्दी से नियंत्रकों और विचारों में निर्धारित कर सकें कि हमारे पास किस प्रकार का उपयोगकर्ता है।

उसके बाद हम 2 मॉडल बनाएंगे: ग्राहक और कार्यकारी। माइग्रेशन में, आप किसी भी डेटा को प्रत्येक प्रकार के उपयोगकर्ता (पासवर्ड, उपस्थिति, आदि) के लिए पंजीकृत कर सकते हैं, दोनों मॉडलों में, उपयोगकर्ता के साथ संवाद करने के लिए, आपको इसे पंजीकृत करने की आवश्यकता है:

1. has_one: user ,: as =>: character ,: आश्रित =>: नष्ट

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

मैंने user_observer (रेल g ऑब्ज़र्वर उपयोगकर्ता) भी जोड़ा है, जहाँ मैंने यह कोड लिखा है:

1. क्लास यूजरऑब्जर्वर <ActiveRecord :: ऑब्जर्वर
2. def_create (उपयोगकर्ता) से पहले
3. build_character_for उपयोगकर्ता
4. अंत
6. निजी
7. def build_character_for (उपयोगकर्ता)
8. user.character = user.character_type.classify.constantize.create!
9. अंत
10. अंत

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

उसके बाद, मैंने इस पर्यवेक्षक को config / application.rb में जोड़ा:

1. config.active_record.observers =: user_observer

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

याद रखें, मैंने कहा कि पंजीकरण करते समय, उपयोगकर्ता को यह चुनना होगा कि वह कौन बनना चाहता है? मेरे पास यह रेडियो है, लेकिन आप आसानी से चयन कर सकते हैं। चयनित प्रकार के आधार पर, उन्हें "ग्राहक" या "कार्यकारी" वापस करना चाहिए। और, तदनुसार, प्रत्येक उपयोगकर्ता बनाने से पहले, हम उसके लिए एक ग्राहक या एक निष्पादक बनाते हैं। उपरोक्त कोड को इस प्रकार लिखा जा सकता है:

1. अगर user.character_type == "ग्राहक"
2. user.character = Customer.create!
3. अन्यथा
4. user.character = Executive.create!
5. अंत

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

लेकिन यह किसी भी तरह लंबा और असुविधाजनक है, सहमत हैं।

Devise'om के साथ, अब आप Canan जा सकते हैं। यह भी प्रलेखन के अनुसार स्थापित करने की आवश्यकता है, और फिर दोनों प्रकार के उपयोगकर्ताओं के लिए अलग-अलग नियम निर्धारित करें। उदाहरण के लिए, कुछ इस तरह:

1. वर्ग की क्षमता
2. कैनैन शामिल करें :: योग्यता
4. आरंभीकृत करना (उपयोगकर्ता)
5. उपयोगकर्ता || = उपयोगकर्ता नई
7. अगर user.admin? # एडमिन अकाउंट
8. कर सकते हैं: प्रबंधन, सब
9. अन्यथा
10. अगर user.customer # ग्राहक खाता
11. # रेस्टफुल
12. पढ़ सकते हैं: दस्तावेज़
13. कर सकते हैं: बनाएँ, दस्तावेज़
14. कर सकते हैं: अद्यतन, दस्तावेज़,: customer_id => user.character.id
15. कर सकते हैं: पढ़ें, टिप्पणी करें
17. # संग्रह
18. कर सकते हैं: व्यक्तिगत, दस्तावेज़
20. elsif user.existent? # कार्यकारी खाता
21. # रेस्टफुल
22. पढ़ सकते हैं: दस्तावेज़
23. कर सकते हैं: पढ़ें, टिप्पणी करें
24. कर सकते हैं: बनाएँ, टिप्पणी करें
25. कर सकते हैं [: अद्यतन,: नष्ट], टिप्पणी,: Executive_id => user.character.id
27. # सदस्य
28. कर सकते हैं: में शामिल होने, दस्तावेज़
29. कर सकते हैं: छुट्टी, दस्तावेज़
31. # संग्रह
32. कर सकते हैं: ड्राफ्ट, टिप्पणी
33. कर सकते हैं: संग्रह, टिप्पणी
34. अंत
35. अंत
36. अंत
37. अंत

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

चलिए कुछ ऐसा ही कहते हैं। इस प्रकार, दोनों ग्राहकों और कलाकारों के पास एक ही नियंत्रक / संसाधनों तक पहुंच है, लेकिन एक ही समय में, प्रत्येक के लिए अलग-अलग कार्यों की अनुमति है।

अब देखने में यह जाँचने के लिए पर्याप्त है कि वर्तमान उपयोगकर्ता एक या कोई अन्य क्रिया कर सकता है या नहीं, और जीवन स्वर्ग जैसा प्रतीत होगा।

1. अगर हो सकता है : join, @document
2. = link_to "जुड़ें", [: join, @document]

* इस सोर्स कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।

अब केवल ऊपर के नियमों में अनुमति देने वालों को "जॉइन" लिंक दिखाई देगा। नियंत्रक को थोड़ा और ठीक करना आवश्यक है, लेकिन मानक प्रलेखन के अनुसार सब कुछ है।

इस तरह, आप साइट पर विभिन्न ब्लॉकों को छिपा सकते हैं और दिखा सकते हैं, और वास्तव में कुछ भी।

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

लेख का परिणाम यह है: ऐसी परिस्थितियां हैं जब पॉलीमॉर्फिक संघों की वास्तव में आवश्यकता होती है और जीवन को बहुत सरल करता है। आपको उन्हें प्रत्येक छेद में कट्टरता से नहीं जोड़ना चाहिए, लेकिन आपको उनके बारे में पता होना चाहिए और उन्हें लागू करने में सक्षम होना चाहिए।

संबंधित लिंक:
github.com/plataformatec/devise
github.com/ryanb/cancan
habrahabr.ru/blogs/ror/79431