रिकर्सिव रेल नेस्टेड संसाधन

Question

मेरे पास प्रोजेक्ट प्रबंधन के लिए रेल एप्लिकेशन है जहां परियोजना और कार्य मॉडल हैं। एक परियोजना में कई कार्य हो सकते हैं, लेकिन एक कार्य में कई कार्य भी हो सकते हैं, विज्ञापन infinitum।

नेस्टेड संसाधनों का उपयोग करना, हम/परियोजनाओं हो सकता है/1/कार्य,/परियोजनाओं/1/कार्य/नई,/परियोजनाओं/1/कार्य/3/संपादित आदि

हालांकि, आप कैसे प्रतिनिधित्व करते हैं कार्यों की रिकर्सिव प्रकृति वास्तव में? मैं एक अन्य स्तर पर गहरे जाना नहीं चाहते हैं, तो शायद निम्नलिखित करना होगा:

map.resources :tasks do |t| 
    t.resources :tasks 
end 

जो मुझे निम्नलिखित यूआरएल देना होगा:

/tasks/3/tasks/new 
/tasks/3/tasks/45/edit 

या शायद जब यह एक व्यक्ति के काम करने के लिए आता मैं यह कर सकते हैं बस/कार्यों/45/

संपादित करें यह एक उचित डिजाइन है?

कैम

Answer 1

ऐसा कोई कारण नहीं है कि वे decendant यूआरएल होना चाहिए।

तार्किक:

 
/projects/1 --> project 1 
/projects/1/edit (etc) 
/tasks/1  --> task 1 
/project/1/tasks --> task list for project 1 
/project/1/tasks/new 
/project/1/tasks/1/edit -> /tasks/5/edit (redundancy) 
/project/1/tasks/1 -> redirect to /tasks/1 
/tasks/1/project -> redirect to /projects/1 
/tasks/3/tasks --> list of tasks that are children tasks of task 3 
/tasks/3/tasks/5 -> redirect /tasks/5/ (because you don't really need to have a recursive URL) 
/tasks/5/parents -> list of tasks that are parents of tasks 3 
/tasks/5/parents/3 -> redirect /tasks/3/ 

वहाँ की आवश्यकता के लिए यूआरएल साहचर्य हो कोई कारण नहीं IMHO है, आप नहीं पता चला है कि काम 5 कार्य 3 का एक बच्चा कार्य संपादित करने के लिए है की आवश्यकता के लिए जा रहे 5.

Answer 2

एक घोंसले वाले मार्ग से कहीं भी कहीं भी जाना एक बुरा विचार माना जाता है।

के पेज 108 रेल मार्ग से

:

"Jamis Busk a very influential figure in the Rails community, almost as much as David himself. In February 2007, vis his blog, he basically told us that deep nesting was a _bad_ thing, and proposed the following rule of thumb: Resources should never be nested more than one level deep."

अब कुछ इस के साथ तर्क है (जो पेज 109 पर चर्चा की है) लेकिन आप नेस्टिंग कार्यों के बारे में कार्यों के साथ बात कर रहे हैं जब यह बस ज्यादा समझ में नहीं आता है।

मैं आपके समाधान से एक अलग तरीके से संपर्क करूंगा और जैसा कि ऊपर बताया गया था, एक परियोजना में कई कार्य होना चाहिए, लेकिन कई कार्यों के लिए एक कार्य के लिए सही नहीं लगता है और शायद उन्हें उप-कार्यों के रूप में फिर से नामित किया जाना चाहिए या उनके जैसे की कुछ और।

Answer 3

मैं वर्तमान में एक प्रोजेक्ट पर हूं जो कुछ समान करता है। मैंने जो जवाब दिया वह बहुत ही सुरुचिपूर्ण था, मैंने एक parent_id कॉलम जोड़ा जो किसी अन्य कार्य को इंगित करता था। जब अपने मॉडल कर रही है, निम्न करने के लिए सुनिश्चित करें:

belongs_to :project 
belongs_to :parent, :class_name => "Task" 
has_many :children, :class_name => "Task", :foreign_key => "parent_id" 

... और फिर आप से प्रत्यावर्तन कर सकते हैं:

def do_something(task) 
    task.children.each do |child| 
    puts "Something!" 
    do_something(child) 
    end 
end  

इस तरह, आप अपनी मूल द्वारा या द्वारा अपने कार्यों को संदर्भित कर सकते हैं इसके बच्चे जब आपके मार्गों कर रही है, आप

/project/:project_id/task/:task_id 

से हमेशा एक ही काम पर जाना होगा, भले ही यह एक माता पिता या बच्चों पड़ सकता है।

बस यह सुनिश्चित करें कि आपके पास कोई ऐसा कार्य नहीं है जिसके माता-पिता अपने बच्चे के समान हों या अन्यथा आप सभी बच्चों को खोजने के लिए अपना रिकर्सन करते समय एक अनंत लूप में जाएंगे।यह सुनिश्चित करने के लिए कि आप ऐसा नहीं करते हैं, आप अपनी सत्यापन स्क्रिप्ट में स्थिति जोड़ सकते हैं।

यह भी देखें: acts_as_tree