Forum: Ruby on Rails Problem with RoR's controller getting too large

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
D3de84309009607577a3f9eb696f828f?d=identicon&s=25 shurain (Guest)
on 2007-05-02 03:06
(Received via mailing list)
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?
588ab1c0a5610a7e160a3b101abb91e6?d=identicon&s=25 MichaelLatta (Guest)
on 2007-05-02 05:10
(Received via mailing list)
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.

D3de84309009607577a3f9eb696f828f?d=identicon&s=25 shurain (Guest)
on 2007-05-02 06:48
(Received via mailing list)
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:
9d1f5d2d9de70bd9a934f557dc95a406?d=identicon&s=25 Daniel ----- (liquid)
on 2007-05-02 06:59
(Received via mailing list)
On 5/2/07, shurain <> wrote:
> 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.

I'm not sure what the issue is.   Michael is correct when he says you
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 )

in your view

<%= display stuff for posts -%>

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

Is that along the lines of what your after?
5baca72f595aed11b919133fe2483a79?d=identicon&s=25 Klondike (Guest)
on 2007-05-02 08:08
(Received via mailing list)

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

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
D3de84309009607577a3f9eb696f828f?d=identicon&s=25 shurain (Guest)
on 2007-05-02 08:49
(Received via mailing list)
My thoughts have been settled, thx everyone.
Ce2b12075dd1268ebc1a4a3a2257ada2?d=identicon&s=25 John Postlethwait (Guest)
on 2007-05-03 02:04
(Received via mailing list)
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)

A post model can have many comments (has _many :comments) giving you
access to those comments through the associations in the models.
This topic is locked and can not be replied to.