attr_accessible(*attributes) & attr_protected(*attributes) के बीच क्या अंतर है? उदाहरण अच्छे होंगे।attr_accessible (* विशेषताएँ) और attr_protected (* विशेषताएँ) के बीच क्या अंतर है?
मुझे लगता है कि कई डेवलपर्स इन्हें अपने मॉडल में उपयोग करते हैं। मैं मतभेदों के लिए गुमराह किया, लेकिन मुझे बिल्कुल नहीं मिला कि वे क्या हैं। विभिन्न परिदृश्यों में महत्व और इसकी आवश्यकता क्या है?
attr_accessible (documentation) कहते हैं, "निर्दिष्ट विशेषताओं से उपलब्ध हैं और अन्य सभी सुरक्षित हैं" (whitelisting के रूप में यह के बारे में सोच।)
जबकि
attr_protected (documentation) कहते हैं, "निर्दिष्ट विशेषताओं की रक्षा की और कर रहे हैं अन्य सभी सुलभ हैं "(blacklisting के रूप में इसके बारे में सोचें।)
ए संरक्षित विशेषता वह है जिसे केवल स्पष्ट रूप से संशोधित किया जा सकता है (उदाहरण के लिए विशेषता =) और बड़े पैमाने पर असाइनमेंट के माध्यम से अपडेट नहीं किया जा सकता है (उदा। model.update_attributes का उपयोग करके या गुणों को new पर पास करके)। बड़े पैमाने पर असाइनमेंट के माध्यम से संरक्षित विशेषता को अद्यतन करने के प्रयास पर व्यवहार mass_assignment_sanitizer सेटिंग (नीचे दिए गए अपडेट को देखें) पर निर्भर करता है।
क्लासिक उदाहरण होगा यदि User मॉडल में is_admin विशेषता थी, तो आप फॉर्म सबमिशन को रोकने के लिए उस विशेषता को सुरक्षित कर सकते हैं जो किसी भी उपयोगकर्ता को व्यवस्थापक के रूप में सेट करने की अनुमति देगा।
उदाहरण:
class User < ActiveRecord::Base
# explicitly protect is_admin, any new attributes added to the model
# in future will be unprotected so we need to remember to come back
# and add any other sensitive attributes here in the future
attr_protected :is_admin
end
के साथ तुलना में:
class User < ActiveRecord::Base
# explicitly unprotect name and bio, any new attributes added to the model
# in the future will need to be listed here if we want them to be accessible
attr_accessible :name, :bio
end
अब, यह सोचते हैं is_admin विशेषता सुरक्षित है:
> u = User.find_by_name('mikej')
> u.is_admin?
false
> u.update_attributes(:name => 'new name', :is_admin => true)
> u.is_admin?
false
> u.name
"new name"
> u.is_admin = true # setting it explicitly
> u.save
> u.is_admin?
true
अद्यतन: रेल के बाद के संस्करण अवधारणा को पेश कियाबड़े पैमाने पर असाइनमेंट के माध्यम से संरक्षित विशेषताओं को अद्यतन करने के प्रयासों पर व्यवहार को नियंत्रित करने के लिए जन असाइनमेंट sanitizer का। रेल 3.2 में और बाद में इसे कॉन्फ़िगरेशन में mass_assignment_sanitizer सेट करके नियंत्रित किया जा सकता है। डिफ़ॉल्ट केवल प्रयासों को लॉग करना है और कोड निष्पादन जारी रखने की अनुमति देना है, लेकिन विकास के लिए मानक पर्यावरण कॉन्फ़िगरेशन इसे :strict पर सेट करता है जो संरक्षित विशेषता को अद्यतन करने के प्रयास पर अपवाद के रूप में उठाता है।
attr_accessible बड़े पैमाने पर काम के लिए एक सफेद सूची है ...
class Foo < ActiveRecord::Base #has attributes foo and bar
attr_accessible :foo
end
f = Foo.new :foo => "test", :bar => "test"
f.foo #=> "test"
f.bar #=> nil
attr_proteceted बड़े पैमाने पर काम के लिए एक काली सूची है ...
class Foo < ActiveRecord::Base #has attributes foo and bar
attr_protected :bar
end
f = Foo.new :foo => "test", :bar => "test"
f.foo #=> "test"
f.bar #=> nil
हम उन्हें एक साथ उपयोग कर सकते हैं? – Salil
हां, लेकिन गुण अलग-अलग हो सकते हैं – fl00r
नहीं, आप केवल एक या दूसरे का उपयोग कर सकते हैं। यदि आप कक्षा में दोनों शामिल करते हैं तो कक्षा को पहली बार लोड होने पर आपको कोई त्रुटि दिखाई नहीं देगी, लेकिन शायद यह स्वयं को 'नोमूथ एरर' के रूप में प्रकट करेगी: जब आप इसकी अपेक्षा नहीं करते थे तो आपके पास शून्य वस्तु होती है! 'जब आप उपयोग करने का प्रयास करते हैं कक्षा। – mikej