रेल में रीस्टफुल डीसीआई संदर्भ

Question

मैंने पहली बार Data, context, and interaction (डीसीआई) के बारे में this blog post के माध्यम से सीखा। अवधारणा से प्रभावित, मैंने इसे अपने अगले रेल आवेदन में बनाने के लिए प्रयास किया। चूंकि डीसीआई एमवीसी के साथ मिलकर काम करता है, मैंने सोचा कि एपीआई को एक ही समय में रीस्टफुल करना मुश्किल नहीं होगा। इसलिए मैंने एक विश्वसनीय संसाधन बनाया, Report और इसे विभिन्न संदर्भों के साथ विस्तारित किया। जिस तरह से मैंने रेल में संदर्भ लागू किए थे, वह नियंत्रक क्रियाओं को बढ़ाने वाले मॉड्यूल के लिए एक निर्देशिका, /app/contexts/ बना रहा था। तो मेरी reports_controller.rb इस तरह दिखता है:

class ReportsController < ApplicationController 
    before_filter :only => :new do |c| 
    c.switch_context("submission") 
    end 

    # GET /reports 
    def index 
    @context.report_list 
    end 

    # GET /reports/1 
    def show 
    @context.display_report 
    end 

    # GET /reports/new 
    def new 
    @context.new_report 
    end 

    # GET /reports/1/edit 
    def edit 
    @context.edit_report 
    end 

    # POST /reports 
    def create 
    @context.create_report 
    end 

    def update 
    @context.update_report 
    end 

    # DELETE /reports/1 
    def destroy 
    @context.destroy_report 
    end 

    protected 

    def switch_context(context_name) 
    session[:context] = context_name 
    context = session[:context].camelize.constantize 
    @context ||= self.extend context 
    end 
end 

और application_controller.rb में मैं एक before_filter साथ संदर्भ सेट:

class ApplicationController < ActionController::Base 
    before_filter :contextualize 
    protect_from_forgery 

    protected 

    # Sets the context of both current_user and self 
    # by extending with /app/roles/role_name 
    # and /app/contexts/context_name respectively 
    def contextualize 
    # Extend self (ActionController::Base) with context 
    if session[:context] 
     context_class = session[:context].camelize.constantize 
     if current_user.allowed_contexts.include?(context_class) 
     context_class = current_user.context if context_class == Visiting 
     else 
     context_class = Visiting 
     end 
    else 
     context_class = current_user.context 
    end 
    @context ||= self.extend context_class 
    end 
end 

सूचना मैं नियंत्रक संदर्भ के अलावा एक Role साथ current_user का विस्तार।

यहाँ यह कैसे काम करता है:

1. एक उपयोगकर्ता के लॉग इन
2. उपयोगकर्ता की भूमिका RegisteredUser है।।
3. RegisteredUser का डिफ़ॉल्ट संदर्भ Search है (जैसा कि /app/roles/registered_user.rb में परिभाषित किया गया है)।
4. Search संदर्भ के अंदर, उपयोगकर्ता केवल प्रकाशित रिपोर्ट देख सकते हैं।
5. उपयोगकर्ता "नई रिपोर्ट बनाएं" बटन दबाता है और संदर्भ Submission में बदल दिया गया है और current_user के सत्र में संग्रहीत किया गया है।
6. उपयोगकर्ता फिर एक बहु-चरण फ़ॉर्म के माध्यम से एक रिपोर्ट जमा करने के लिए आगे बढ़ता है।
7. प्रत्येक बार जब उपयोगकर्ता /app/contexts/submission.rb फ़ॉर्म के माध्यम से कदम से रिपोर्ट करके रिपोर्ट सहेजता है तो कार्रवाई कार्रवाई को संभालती है।

कई अन्य संदर्भ (समीक्षा, संपादकीय, आदि) और भूमिकाएं (सह-लेखक, संपादक इत्यादि) हैं।

अब तक इस दृष्टिकोण ने अधिकांश भाग के लिए अच्छा काम किया है। लेकिन एक दोष है: जब कोई उपयोगकर्ता एकाधिक ब्राउज़र विंडो खोलता है और उनमें से एक में संदर्भ बदलता है, तो अन्य सभी विंडो गलत संदर्भ में होंगी। यह एक समस्या हो सकती है यदि उपयोगकर्ता बहु-चरण फ़ॉर्म के बीच में है और फिर Search संदर्भ में एक विंडो खोलता है। जब वह फॉर्म पर वापस स्विच करता है और "अगला" हिट करता है, तो नियंत्रक Submission संदर्भ के बजाय Search संदर्भ द्वारा परिभाषित क्रिया निष्पादित करेगा।

1. नाम स्थान संदर्भ नाम के साथ Report संसाधन:

   इस लगभग 2 संभव तरीके है कि मैं के बारे में सोच सकते हैं। तो उपयोगकर्ता यूआरएल जैसे /search/reports और /submission/reports/1 पर जायेगा। यह मेरे लिए बिल्कुल प्रतीत नहीं होता है और मैं यूआरएल को यथासंभव स्वच्छ रखूंगा।

2. संदर्भ नाम को एक छिपे हुए क्षेत्र में रखें। इस विधि के लिए डेवलपर्स को साइट पर हर रूप में छिपे हुए फ़ील्ड को रखना याद रखना होगा, और यह GET अनुरोधों के लिए काम नहीं करता है।

क्या इस समस्या के आसपास कोई अन्य तरीका है, या बेहतर समग्र कार्यान्वयन?

मैं this project के बारे में पता है, लेकिन यह हमारी जरूरतों के लिए भी सीमित है।

Answer 1

आप कई संदर्भों के लिए अनुमति देने के लिए तो जाहिर है आप जानकारी जो कुछ भंडारण जो टैब के बीच साझा नहीं है में वर्तमान संदर्भ निर्धारित करता है डाल चाहिए चाहते हैं। रैक/रेल में लागू किए गए सत्र, कुकीज का उपयोग करते हैं, और टैब टैब के बीच साझा किए जाते हैं।

बस कुछ में संदर्भ में कहें, कि साझा नहीं है। एक संदर्भ = दर्शक यूआरएल पैरामीटर के बारे में कैसे?

बाकी बात करने के लिए मुझे लगता है कि यह विवादास्पद है या नहीं, एक संसाधन के उसी या अन्य संदर्भों में नहीं है। कोई तर्क दे सकता है कि "विज़िटिंग" उपयोगकर्ता के लिए एक रिपोर्ट "व्यवस्थापक" उपयोगकर्ता के लिए एक रिपोर्ट से अलग है। उस स्थिति में एक RESTy दृष्टिकोण शायद अनुरोधों को नामित करेगा (जो संदर्भ को यूआरएल में फिर से रखता है), उदा।/विज़िट/रिपोर्ट/1 बनाम/प्रशासन/रिपोर्ट/1।

और एक तीसरा रास्ता URL में संदर्भ डाल करने के लिए डोमेन नाम के हिस्से के रूप में इसका इस्तेमाल होगा।