Problem with RoR's controller getting too large

rubyonrails-talk
1

Let's assume that there are two models Post and Comment. If we have a controller dealing with both of these models, it wouldn't take long before the controller grows too big to maintain. As far as I understand, this happens because a controller tries to handle all the actions allowed by the user. If I change the perspective and create a controller per model the controller getting too large is fixed but I have another problem.

I don't see any good way of accessing multiple controllers (or models) in one view. There are times when I have to see an instance of a Post "AND" the comments which belongs to the post. I've heard that it can be solved by using components but that has been deprecated and I've heard that there are some issues which discourage its use. Using application.rb doesn't really help because it still makes the controller grow large. Is there any clean solution to this?

2

I am not sure what the problem is.

You can structure the application any way you would like. You can have 200 controllers each handling any part of the user actions you like. ROR does not impose any restrictions on this.

If you are asking about generated scaffolds then I can suggest that you build your own pages or use a better scaffolding like ActiveScaffold. If you are asking about best practices I can suggest some things to think about:

1) When a simple structure becomes too large or unmanageable you need to partition the functions. 2) Partitioning works best when you can cleanly separate some things from another. 3) One common partitioning is to place all CRUD actions for one model in a controller. But, this is only one strategy. 4) Another approach is to partition based on use cases. You could put all ATM functions in one controller, all teller functions in another, all branch manager functions in another, even though all controllers deal with the same model classes. This is just another strategy. 5) Another strategy is to combine 3&4 for sets of classes that are tightly coupled.

While most of the scaffolding systems support 3 it is not necessarily the best. Strategy 4 is actually better in my opinion as it couples the logical functions together rather than the mere fact that they share data. Probably the ideal would be to have each use case in its own controller so that all the steps in a logical process are close together. This assumes that the application is more than just CRUD actions, as simple CRUD would not create a controller size problem.

Michael

3

Let me rephrase the problem.

I wish to be able to show an article using postcontroller. I would also like to create a comment using commentcontroller. I want to see them both in one view.

related thread: http://railsforum.com/viewtopic.php?id=5004

4

I’m not sure what the issue is. Michael is correct when he says you can have as many controllers as you like.

If you want to see both a post and comment in one view use partials

eg something like (posts)

def show

@post = Post.find_by_id( :id )

end

in your view

<%= display stuff for posts -%>

<%= render :partial => ‘/comment/detail’, :collection => @post.comments %>

Is that along the lines of what your after?

5

shurain,

By making a controller for each model, this doesn't mean you can't deal with other models in the views related to that controller.

In your situation, your comment controller may have only 3 actions: create, update, and destroy, all of which are reached through form submissions. In that case, your comments controller would control no views!

But this is fine -- put actions in the comment controller which *primarily* deal with comments, and actions in the posts controller which *primarily* deal with posts. That's the best you, or any of us, can do -- and it works just fine.

-- Eric

6

My thoughts have been settled, thx everyone.

7

Helpers and model associations (has_many, belongs_to, etc) may be what you could look in-to for the future. You could then do something like:

post = Post.find(:first) post.comments

A post model can have many comments (has _many :comments) giving you access to those comments through the associations in the models.