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?

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,