I am starting to learn rails and I went through the guide and a couple
of tutorials. Even though I understand controllers or at least I can
use them I can't see yet the whole picture.
Why do you need several controllers for a single application? If a
controller is just a class whose methods interface with models and
views, why not have a single controller for the whole application?
Can someone please comment on this maybe with an example on an obvious
situation where having two controller makes more sense than having
just one?
Thanks for the reference Bill. I do know about MVC, even though I am
far from an expert in Software Design Patterns.
Still doesn't explain what's the point of several controllers within
the same instance of a web application. Or have I missed something?
Still doesn't explain what's the point of several controllers within
the same instance of a web application. Or have I missed something?
Okay, all MVC/design patterns/theory aside, from a purely practical,
simplistic point of view, what will your single controller's edit method
look like when you have 1,752 models in your application?
Something like (assuming you have to pass the model name in params since
you have only 1 controller)
Hi,
Why do you need several controllers for a single application? If a
controller is just a class whose methods interface with models and
views, why not have a single controller for the whole application?
Rails adheres to the Model-View-Controller architectural pattern.
Take a browse through some of these to gain an understanding of why.
model view controller - Google Search
Thanks for the reference Bill. I do know about MVC, even though I am
far from an expert in Software Design Patterns.
Still doesn't explain what's the point of several controllers within
the same instance of a web application. Or have I missed something?
The MVC pattern tells us where to put 'things' so that we know where
to look for them later. In the simplest case, there is a 'stack' from
the UI (the view) to the data (the model). The controller acts as the
traffic cop. That's what MVC tells us to do. In a RESTful
application (REST may be the part you're 'missing' about Rails. see
REST - Wikipedia) we CRUD
our data via the methods in our controller. Except for methods
supporting Ajax updates, you will typically only find 7
actions/methods in a Rails controller: index/list, new, create, show,
edit, update, and destroy.
Let's assume a simple application that has 2 tables: customers and
addresses. The Model objects mapping to these are, by Rails'
convention, Customer and Address. Assume further that there's a one
-> many relationship between Customer and Address. In our
application, we want to be able to CRUD addresses for a particular
customer, and we also want to view all the addresses independently of
customer. Perhaps we want a heat map, for example, of addresses on
file. For the first, we use the Customer stack. For the second, we
use the Address stack. While we could do it differently, with one
controller, it wouldn't be a good example of the MVC pattern, and it
wouldn't be RESTful.
Thanks for the reference Bill. I do know about MVC, even though I am
far from an expert in Software Design Patterns.
Still doesn't explain what's the point of several controllers within
the same instance of a web application. Or have I missed something?
The MVC pattern tells us where to put 'things' so that we know where
to look for them later. In the simplest case, there is a 'stack' from
the UI (the view) to the data (the model). The controller acts as the
traffic cop. That's what MVC tells us to do. In a RESTful
application (REST may be the part you're 'missing' about Rails. see
REST - Wikipedia)
Probably not. Rails MVC predates REST. REST is great, but it is
orthogonal to MVC. Don't confuse the OP even further.
If you think have a better answer, one that will answer the OP's
question better, then put it forth. Otherwise STFU. I, for one, tire
of your posts. You mostly just criticize / chastise, rarely
contributing.
My simple explanation is it's a matter of organization.
We create controllers to organize our code and to add a little bit of
context for the users who actually look at URLs.
If you have a very simple app, one controller may suffice. But once
your app starts providing a number of features, it may become
advantageous to divide those features up into categories that make
sense. As one very simple example, if you had a site where you sold
products, you might have a controller called Catalog where you handle
the presentation of items; but you might also want to have a User or
Profile controller for managing the activities related to users
(entering/editing addresses, persistent billing data, etc.)
example.com/catalog/item?...
example.com/user/order_history
My answer completely ignores REST, because I learned and used MVC long
before I knew what REST was.
I just want to say thanks for your excellent example and say that I
think the bit I am missing is indeed the fact that Rails uses REST,
and REST uses the URL of the application which in turn is what tells the
framework which controller to use! (hope I didn't mess anything up in
these lines)
Okay, all MVC/design patterns/theory aside, from a purely practical,
simplistic point of view, what will your single controller's edit method
look like when you have 1,752 models in your application?
Something like (assuming you have to pass the model name in params since
you have only 1 controller)
I just want to say thanks for your excellent example
You are very welcome. Glad it helped!
and say that I
think the bit I am missing is indeed the fact that Rails uses REST,
and REST uses the URL of the application which in turn is what tells the
framework which controller to use! (hope I didn't mess anything up in
these lines)
You're very close. REST tells us what URLs we should use in the
default CRUD cases. Rails Routes tells Rails how to find the right
controller / action to invoke based on the URL.
I will look more closely at REST.
In conjunction, you'll probably do well to look at
Also, Rails give us a rake task we can use at any time to see what
routes our application can understand: rake routes RAILS_ENV=the
environment you're using
If you think have a better answer, one that will answer the OP's
question better, then put it forth.
Everything I would have contributed has already been said. I suspect if
I'd repeated what others had already said, I would have incurred your
wrath for that.
Otherwise STFU.
If you don't like what I posted, you can tell me that without profanity.
You owe me an apology -- not for what you said, but for how you chose to
say it.
I, for one, tire
of your posts.
Then you are welcome to skip them. There are posters for whom I do this
routinely, but you won't see me telling them to shut up.
You mostly just criticize / chastise, rarely
contributing.
When the OP is already confused, I think advice not to further confuse
him with factual errors *is* contributing to the discussion. I usually
like your posts, but factual errors regarding the nature of REST and MVC
are not helpful.
I'm writing an application to track calibrated assets. If I were to
have one controller it would have to be able to update(delete, create,
read) the items,vendors, issues...etc. It would be huge and certainly
unwieldy, not to mention very difficult to do in the Rails framework.
The Items controller deals with the items table. All the views to the
data happens through this controller which makes the code easy to read
and understand.
I think the issue here is about how to plan and build your
application. The controllers are the building blocks for the app and
so serve as the first layer of design that you are using to solve the
problem.
