कई पृष्ठों पर एक ही फॉर्म रखने के लिए रेल का सर्वोत्तम अभ्यास

Question

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

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

जिस समस्या में मैं चल रहा हूं वह है जब पोस्ट फॉर्म सही ढंग से पूरा नहीं होता है, डिफ़ॉल्ट रूप से पोस्टकंट्रोलर :: विधि प्रस्तुत करने के प्रश्न/new.html.erb बनाएं, भले ही फ़ॉर्म होम पेज से सबमिट किया गया हो (/ घर/index.html.erb)।

मैंने "submitting_controller" और "submitting_action" सबमिट करने के लिए आंशिक रूप में फ़ॉर्म को बदलने का प्रयास किया, और पोस्टकंट्रोलर :: बनाएं, जब @ post.save? == झूठी, मैं कार्रवाई => "../submitting_controller/submitting_action" प्रस्तुत करता हूं (जो थोड़ा हैकी है, लेकिन आपको गैर-पोस्ट नियंत्रक से क्रियाएं प्रस्तुत करने देता है)।

यह सतह पर ठीक काम करने लग रहा था। अपूर्ण रूप को उस दृश्य में प्रस्तुत किया गया था जो इसे सभी सही @ post.errors संदेश आदि के साथ प्रस्तुत किया गया था। समस्या यह थी कि पृष्ठों पर मौजूद अन्य सभी डेटा दिखाई नहीं दे रहे थे, क्योंकि वास्तविक सबमिटिंग_कंट्रोलर/सबमिट करने की विधि को नहीं बुलाया गया था, बस संबंधित दृश्य (Remeber, मैंने एक रेंडर किया है जो एक रीडायरेक्ट_to की बजाय इंस्टेंस ऑब्जेक्ट्स को संरक्षित करता है जो @post इंस्टेंस ऑब्जेक्ट को सुरक्षित नहीं करता है जिसमें सभी त्रुटि संदेश और सबमिट किए गए मान हैं।)

जहां तक ​​मैं देख सकता हूं कि मेरे पास दो विकल्प हैं :

1) मैं @ post.save पर सत्र में @ पोस्ट ऑब्जेक्ट स्टोर कर सकता हूं? PostController में विफल रहता है :: सबमिट करें, redirect_torollitting/submitting_action को रीडायरेक्ट करें, जिस बिंदु पर मैं सत्र के बाहर @ पोस्ट ऑब्जेक्ट खींचता हूं और फॉर्म/त्रुटि संदेशों को फिर से पॉप्युलेट करने के लिए इसका उपयोग करता हूं। (जहां तक ​​मैं समझता हूं, सत्र में वस्तुओं को संग्रहित करना रेल में बीएडी अभ्यास है)

2) मैं विभिन्न सबमिटिंग_कॉलर/सबमिटिंग_एक्शन से गैर-पोस्ट निर्माण फ़ॉर्म डेटा खींचने के लिए उपयोग किए गए सभी तर्कों को स्थानांतरित कर सकता हूं, इसे ApplicationController, PostController :: में एक विशाल स्विच कथन बनाएं सबमिट करने के लिए सबमिट करें/कंट्रोलिंग/सबमिट करने के लिए बनाएं और प्रत्येक सबमिट करने वाले पृष्ठ के प्रस्तुत करने के लिए आवश्यक सभी अतिरिक्त डेटा को पकड़ने के लिए एप्लिकेशन नियंत्रक में विधियों को कॉल करें।

विचार रेल के भीतर ऐसा करने का सबसे अच्छा तरीका है?

Answer 1

किसी भी मौके से आपका पोस्ट मॉडल प्रत्येक मॉडल के साथ संबंधों के संबंध में है जो नियंत्रक है जिसका उपयोग आप अपना फॉर्म प्रस्तुत करने के लिए करेंगे? क्या आप पोस्ट नियंत्रक में Post.create(params[:post]) से परे कोई विशेष प्रसंस्करण कर रहे हैं?

यदि आपने पहले प्रश्न के लिए हाँ का उत्तर दिया है और दूसरे को नहीं, तो आप प्रत्येक नियंत्रक को accepts_nested_attributes_for जोड़कर न्यूनतम मैंगलिंग के साथ प्राप्त कर सकते हैं जिस पर उपयोगकर्ता कोई पोस्ट बना सकता है।

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

क्या आप अपने दो विकल्पों पर विचार पर विचार के रूप में,

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

2) देखें robertpostill की प्रतिक्रिया

Answer 2

यह इस बिंदु के बारे में है कि आप AJAX के उपयोग के माध्यम से किसी पृष्ठ के अनुभागों को अद्यतन करने के लिए पूर्ण पृष्ठ अपडेट से आगे बढ़ते हैं। ऐसी चीजों का एक समूह है जिन पर आपको विचार करना चाहिए लेकिन अधिकांश रेल-एस्क दृष्टिकोण एक AJAX प्रतिक्रिया और एक सादे HTML प्रतिक्रिया के बीच प्रतिक्रिया को विभाजित करना होगा। this ONLamp article, this register article या the awesome agile web development with rails book देखें। अनिवार्य रूप से आपका नियंत्रक आंशिक प्रस्तुत करने के परिणाम वाले पुराने div को प्रतिस्थापित करने वाला एक नया div प्रस्तुत करता है।

अपने प्रश्न में आप दो दृष्टिकोण का उल्लेख और इसलिए मैं कोशिश करते हैं और आप पर कुछ संकेत दे क्यों और यहाँ क्यों नहीं होगी:

विकल्प 1) Ths विकल्प तोड़ मरोड़ के एक जोड़े के साथ इतना बुरा नहीं है। मुख्य tweak वस्तु को डीबी में एक क्रमबद्ध रूप में स्टोर करने के लिए है। फिर बस धारावाहिक वस्तु की आईडी के चारों ओर पास करें।आपके upsides यह है कि सत्र डेटा जारी रहता है इसलिए एक सत्र को पुनर्प्राप्त करना neater है और आपका सत्र प्रकाश रहता है। इसका नकारात्मक पक्ष यह है कि आपके डीबी में सत्र क्रॉफ्ट की बाल्टी होने से आपके ऐप को प्रदूषित कर दिया जाएगा और आपको डीबी से अप्रयुक्त सत्र क्रूर की अवधि समाप्त करने के तरीके के बारे में कुछ सोचने की आवश्यकता होगी। मैंने कभी इस अंत को अच्छी तरह से नहीं देखा है ...

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