new controller?

[Snowbird122]

How do you know when to make a new controller in rails? I can't figure this out.

[vgarcia]

How do you know when to make a new controller in rails? I can't figure this out.

Let's say I'm managing uncategorized content out of a database. That would be one controller. Now let's say I want to assign categories to each piece of content. I would then create a Category controller in addition to the Content controller. Basically when you need to manage a new type of content or you need to create a new section of your application, you should create a new controller.

[samsm]

Ha! I thought you had asked this question before, but now that I look, I see you were asking How do you know when to make a new model?. Both logical questions, really.

There is no limit on the quantity of methods in a controller, so you could have just one controller for an application of any size. That would be kind of silly, it could be difficult to look through that file, keep track of method names, etc. Point is, that when you make separate controllers it is for your own benefit.

I think of a controller as a unit that accomplishes one task. That task could be more or less specific, just depends. Like Vinnie said, any new section could likely use a new controller.

Of course, "section" is vague and could be tricky to define when a processes is elaborate. For example, a "user" controller may include registration, logging in, profile viewing, etc etc , or you could break each of those things into separate controllers. I'm not sure there is a "right" way.

Isn't there an OOP maxim that you shouldn't create more methods than you can keep in your human short term memory (usually 5-10)? Perhaps when you are having trouble keeping track of what a controller is doing, it is time for a new one. You can also apply filters to whole controllers which may help keep things organized.

[Fenrir2]

If your user controller gets too big you can split it into multiple controllers and put them in a user-module to keep them together.

[Snowbird122]

Thanks for the replies. I'm trying to wrap my head around this whole MVC thing. The question about the models still applies - the only response I received was to make a model for every table, but that doesn't quite make sense. There are "join" or "lookup" tables for many-to-many relationships that don't need models and rails can discover automatically if you use the has_and_belongs_to_many keyword, and in the Rails book, it talks about making models that don't depend on a table and are not part of Active Record, so I guess I will only learn from doing it wrong a few times and learning from my mistakes.

As far as controllers, I think your answer confirms what I was thinking - it is a somewhat arbitrary decision - just like when to make a function, but your examples make a lot of sense for rules of thumb.

As far as the OOP maxim on the number of methods in a class, that just doesn't make sense to me. The class should make whatever methods and properties are necessisary to adequately describe the object. There are some examples of classes having overlapping methods, and of course that doesn't make any sense. As Einstein says, things should be as simple as possible, but not simpler.

[samsm]

There are "join" or "lookup" tables for many-to-many relationships that don't need models and rails can discover automatically if you use the has_and_belongs_to_many keyword

Sometimes, habtm should really be a model: http://www.ruby-forum.com/topic/24128#7157

[Snowbird122]

Thanks for the link - that is a good discussion, but is also a real rails turnoff to me. It appears that rails isn't quite ready for some of the complex table relationships that I know I am going to have. I know that I have worked with enough tables and wierd relationships that even the SQL gets hairy. I can't imagine how bad it might get with rails.

I have been kind of ignoring this problem and trusting that when I got to a complex relationship, that rails would be able to handle it, but now I am really wondering. All the examples have really simple table relationships, and I was just thinking that if I could understand all of them, then I would eventually be able to do anything - just like in all other programming languages.

Hmm. Do I have to be DHH and be an Active Record expert to be able to model my database correctly. That is quite discouraging.

[samsm]

Thanks for the link - that is a good discussion, but is also a real rails turnoff to me. It appears that rails isn't quite ready for some of the complex table relationships that I know I am going to have.
...
Hmm. Do I have to be DHH and be an Active Record expert to be able to model my database correctly. That is quite discouraging.

No no no ... you'd have to be as experienced as DHH to know how to take a complex relationship and figure out how to express it in one line in Active Record. Representing it in your model is not as hard. I use his alternate suggestion for that sort of many to many relationship and it is not too difficult.

I like to think that when Active Record fails, "Plan B" for is to write the SQL yourself, aka "Plan A" for a lot of other systems.

[ezmobius1]

You can have arbitrarily large controllers if you need. One thing to keep in mind is that your controller classes have to get instantiated *every time* they handle a request. If your controller is really long this may start to be a performance consideration. I find that when your controller starts to take up more then 3 standard pages then you need to rethink your situation.

Ans yes you will run into the wall with ActiveRecord eventually but not as quick as you might think. And the like samsm said you can always drop to pure sql whenever you need to so where's the loss? You assumably where writing the sql yourself in php right?

[samsm]

Personally, I think it is encouraging that the Active Record people are looking at how to make these relationships easier and seem to have some decent ideas.

[Snowbird122]

Yes, I can write sql with no problems, thanks to years of help from Rudy!

I guess you are right - we can always fall back on sql. I wonder if there are any gotchas with doing this though - like with most types of frameworks that write the sql for you (SAP comes to mind). When you bypass "the system" and start deleting and updating yourself, "the system" gets confused and you are screwed. I know it is stupid to compare rails to SAP, by I just can't help to be weary of working around active record.

[vgarcia]

Yes, I can write sql with no problems, thanks to years of help from Rudy!

I guess you are right - we can always fall back on sql. I wonder if there are any gotchas with doing this though - like with most types of frameworks that write the sql for you (SAP comes to mind). When you bypass "the system" and start deleting and updating yourself, "the system" gets confused and you are screwed. I know it is stupid to compare rails to SAP, by I just can't help to be weary of working around active record.

ActiveRecord won't freak out if you work around it. The only gotchas in AR seem to be if you deviate from convention when designing your tables and columns, not from the data you have in the DB.