आमतौर पर, रेलों में सत्यापन के बारे में केवल अच्छा ही कहा जाता है। आज हम कुछ स्थितियों के बारे में बात करेंगे जहाँ सिस्टम क्रैश हो जाता है।
स्थिति बार
उपयोगकर्ता को पंजीकृत करते समय, हम आमतौर पर पासवर्ड की पुष्टि करना चाहते हैं। कोई समस्या नहीं, जोड़ें: पुष्टिकरण => सत्य। कुछ समय बाद, साइट में एक मोबाइल एप्लिकेशन दिखाई देता है, जिसमें पंजीकरण भी लागू किया जाता है, लेकिन वहां पासवर्ड की कोई पुष्टि नहीं होती है। इस मामले में क्या करना है?
बिल्ली के नीचे समाधान
सबसे लोकप्रिय जवाब: कंट्रोलर में हमने पासवर्ड_ पासवर्ड को हाथों में रखा। एक पल रुकिए। उपयोगकर्ता मॉडल के साथ पासवर्ड पुष्टिकरण का क्या करना है? सामान्य रूप से पासवर्ड की पुष्टि क्या है? और ईमेल की पुष्टि (हाँ, कुछ ऐसा करते हैं)?
स्थिति दो
एक ही पंजीकरण। ईमेल आमतौर पर आवश्यक है। उत्पाद स्वामी सामाजिक के साथ एकीकरण का कार्य जोड़ता है। नेटवर्क। ट्विटर के माध्यम से प्राधिकरण के दस्तावेज को देखने के बाद, हम समझते हैं कि हम ईमेल नहीं देख सकते हैं। कोई, ज़ाहिर है, प्राधिकरण के बाद आपको ईमेल दर्ज करने के लिए कहेंगे, लेकिन हमारे मामले में मैनुअल विरुद्ध है। ईमेल के बिना एक बिंदु को अधिकृत करना भी आवश्यक है, लेकिन पंजीकरण फॉर्म में वैसे भी ईमेल की आवश्यकता होगी। और इस मामले में क्या करना है?
उत्तर मैंने सुना है:
- हम पंजीकरण में सत्यापन को छोड़ देते हैं।
- एक नकली ईमेल डालें - qwerty@twitter.fake.com
- हैक के द्वारा हम त्रुटियों से त्रुटि संदेश को काट देते हैं और दिखावा करते हैं कि सब कुछ ठीक है 0_o।
- आने वाले मापदंडों के आधार पर, मॉडल के अंदर कस्टम सत्यापन शुरू हो जाता है।
क्या ऐसी आवश्यकताओं वाले उपयोगकर्ता मॉडल के लिए ईमेल अनिवार्य है? उत्तर: नहीं, हमारे आवेदन को उसकी अनुपस्थिति में भी सही ढंग से काम करना चाहिए।
लेकिन पंजीकरण फॉर्म के बारे में क्या?
सच्चाई चारों ओर है
यदि आप पहली और दूसरी स्थितियों को करीब से देखते हैं, तो यह स्पष्ट हो जाता है कि फ़ॉर्म HTML टुकड़े से कुछ अधिक है (एपी में, वैसे, कोई html नहीं है, लेकिन वहां "फॉर्म" भी है)। तो यह विशिष्ट स्थितियों में फॉर्म है जो पासवर्ड की पुष्टि, ईमेल की उपलब्धता के बाद से मान्य होना चाहिए यह व्यवहार एक मॉडल का नहीं है, बल्कि एक ठोस प्रतिनिधित्व में एक विशिष्ट रूप का है। मजेदार बात यह है कि कई अन्य रूपरेखाओं में ऐसी कोई समस्या नहीं है। फॉर्म मॉडल
django ,
zend फ्रेमवर्क ,
सिम्फनी ,
yii में है । और रेलों में भी ऐसा ही
करने का प्रयास किया जा रहा है। आप ActiveModel के माध्यम से इस कार्यक्षमता को लागू करने का प्रयास कर सकते हैं।
इस पूरी कहानी में व्यक्तिगत रूप से मुझे क्या परेशानी है कि रेल डेवलपर खुद इन समस्याओं को हल करने का गलत तरीका दिखाते हैं। वे सत्यापनकर्ता जोड़ते हैं: पुष्टिकरण => सच है, वास्तव में मूल पीवीसी सिद्धांत का उल्लंघन करते हैं: मॉडल दृश्य पर निर्भर नहीं है।
हमें अपनी परियोजनाओं के लिए एक समाधान मिल गया है, और अब तक यह आम तौर पर हमें सूट करता है, और एक ही समय में एक और
अच्छी तरह से ज्ञात समस्या को हल करता
है । यह इस तथ्य में निहित है कि विशिष्ट रूपों के लिए हम अपने मॉडल के उत्तराधिकारी बनाते हैं और वास्तव में उनके माध्यम से काम करते हैं। बेशक, यह सबसे स्वाभाविक हैक है, लेकिन अलग-अलग रूपों को लिखने की कोशिश में, मैं मुश्किलों में भाग गया जब नेस्टेड रूपों को लागू करने और इस व्यवसाय को बेहतर समय तक स्थगित कर दिया।
1. हम ऐप्स में टाइप फोल्डर बनाते हैं।
2. वहां base_type.rb जोड़ें
module BaseType extend ActiveSupport::Concern module ClassMethods def model_name superclass.model_name end end end
3. इच्छित प्रकार बनाएँ। एक उदाहरण:
class UserEditType < User include BaseType attr_accessible :first_name, :second_name validates :first_name, :presence => true validates :second_name, :presence => true end
इसलिए सरल विरासत का उपयोग करते हुए, हमने वर्तमान दृश्य और इसके लिए आवश्यकताओं के आधार पर कस्टम सत्यापन के कार्य को हल किया। सच है, आपको कुछ रत्नों के संबंधों को वर्ग के नाम पर ठीक करना होगा, न कि model_name (वाहक के रूप में, उदाहरण के लिए, वर्ग के आधार पर पथ बनाता है), लेकिन अभी तक यह काफी आसानी से हल हो गया है।
इसे टाइप क्यों कहा जाता है और फॉर्म नहीं? एपीआई का कोई रूप नहीं है, लेकिन आवश्यकताएं समान हैं। और टाइप नाम सिम्फनी फ्रेमवर्क से लिया गया है।
अंतिम उदाहरण से पता चलता है कि attr_accessible से संबंधित एक और समस्या हल हो रही है। बेशक, आप यह तर्क दे सकते हैं कि आप इसके लिए विकल्प के रूप में उपयोग कर सकते हैं, लेकिन वास्तव में यह मॉडल पर अतिव्यापी परत के बारे में जानकारी जोड़कर इनकैप्सुलेशन का उल्लंघन करता है।