MaggotChild
2010-Aug-02 09:20 UTC
Rails Strives For DRY. A Lot of REST Routes, Not So DRY.
Most in the Rails community seem stick with 1 controller per resource when using RESTfull routes. This makes sense for a resource with one scope and one view, but once a resource is used with multiple scopes and/or views the amount of code duplication needed to manage these in a single controller can balloon quick. Yet despite the impending chaos, it seems as though people prefer to maintain a controller per resource. Take these examples from Rails sites written by well respected authors: 1. http://tinyurl.com/2d9rl3v find_container() and find_events(): why would one want to do this? This can become unmanageable. If each of these scopes require different view components the same checks will have to be done in the action''s view or when determining the layout. 2. http://tinyurl.com/2679ye3 Look at how many times wall? and blog? have to be called. Not very DRY if you ask me. Rail''s routing gives you these checks for free, why not create a WallCommentsController and BlogCommentsController? If differing views are involved for each of these it seems like a no brainer... but it''s never done. Why? What am I missing? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen Laibow-Koser
2010-Aug-02 13:28 UTC
Re: Rails Strives For DRY. A Lot of REST Routes, Not So DRY.
MaggotChild wrote:> Most in the Rails community seem stick with 1 controller per resource > when using RESTfull routes.As opposed to what alternative?> This makes sense for a resource with one scope and one view, but once > a resource is used with multiple scopes and/or views the amount of > code duplication needed to manage these in a single controller can > balloon quick.Uh, not necessarily. And plugins like make_resourceful can help too.> Yet despite the impending chaos, it seems as though > people prefer to maintain a controller per resource.That''s the way Rails MVC works. How would you avoid this, and why?> > Take these examples from Rails sites written by well respected > authors: > > 1. http://tinyurl.com/2d9rl3v > > find_container() and find_events(): why would one want to do this?One wouldn''t. Those should be in a model class, or possibly a presenter. That much logic doesn''t belong in the controller. Perhaps Jamis is planning to refactor?> This can become unmanageable. If each of these scopes require > different view components the same checks will have to be done in the > action''s view or when determining the layout.I don''t think you''re right about these particular implications, but you''re right that this is poorly written.> > 2. http://tinyurl.com/2679ye3 > > Look at how many times wall? and blog? have to be called. Not very DRY > if you ask me.Nor if you ask me. Some refactoring and a polymorphic association would really help here.> Rail''s routing gives you these checks for free, why not create a > WallCommentsController and BlogCommentsController?Because that would be even less DRY Polymorphism is probably what''s wanted here.> If differing views > are involved for each of these it seems like a no brainer... but it''s > never done. Why? What am I missing?You''re apparently missing the fact that a comment is a comment, and the comments controller shouldn''t need to know about the type of its parent object. This is why polymorphism is the right solution. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.