Controllers, what? why?
Paulo J. Matos
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,
--
PMatos
Bill Walton
On Mon, Jun 21, 2010 at 6:04 AM, Paulo J. Matos <pocm...@gmail.com> wrote:
> 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.
http://www.google.com/search?q=model+view+controller&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
Welcome aboard!
Best regards,
Bill
Paulo J. Matos
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?
--
PMatos
Ar Chron
> 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)
@object = params[:model].constantize.find(params[:id])
will get you only so far...
--
Posted via http://www.ruby-forum.com/.
Bill Walton
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
http://en.wikipedia.org/wiki/Representational_State_Transfer) 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.
HTH,
Bill
Marnen Laibow-Koser
> Hi Paulo,
>
> On Mon, Jun 21, 2010 at 8:32 AM, Paulo J. Matos <pocm...@gmail.com>
> wrote:
>>> Take a browse through some of these to gain an understanding of why.
>>> http://www.google.com/search?q=model+view+controller&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
>>>
>>
>> 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
> http://en.wikipedia.org/wiki/Representational_State_Transfer)
Probably not. Rails MVC predates REST. REST is great, but it is
orthogonal to MVC. Don't confuse the OP even further. :)
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
bill walton
> 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.
Bill
michael_teter
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.
Paulo J. Matos
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)
I will look more closely at REST.
Cheers,
Paulo Matos
Bill Walton <bwalt...@gmail.com> writes:
>
> 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
> http://en.wikipedia.org/wiki/Representational_State_Transfer) 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.
>
> HTH,
> Bill
--
PMatos
Paulo J. Matos
>
> 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)
>
> @object = params[:model].constantize.find(params[:id])
>
> will get you only so far...
Simple and to the point. Thanks!
--
PMatos
Frederick Cheung
On Jun 21, 3:19 pm, Marnen Laibow-Koser <li...@ruby-forum.com> wrote:
>
> Probably not. Rails MVC predates REST. REST is great, but it is
> orthogonal to MVC. Don't confuse the OP even further. :)
before Rails started out (although MVC itself is of course older)
Fred
Bill Walton
On Mon, Jun 21, 2010 at 12:34 PM, Paulo J. Matos <pocm...@gmail.com> wrote:
> Bill,
>
> 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
http://guides.rubyonrails.org/routing.html
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
Again, welcome aboard!
Best regards,
Bill
Marnen Laibow-Koser
> On Mon, 2010-06-21 at 16:19 +0200, Marnen Laibow-Koser wrote:
>> 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.
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.
>
> Bill
Marnen Laibow-Koser
OK, but it still predates the use of REST in Rails, which is what I was
getting at.
>
> Fred
Agoofin
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.
Hope this helps