Welcome to Rails!!!
About Models, Views, and Controllers…
These concepts are things that make up the MVC architectural pattern.
The benefit of doing MVC is that it helps separate logic and
responsibility in applications… Compare the architecture shown in this
blog posting on application layering by Keith Ray -
http://homepage.mac.com/keithray/blog/2006/09/22/ - and think of the
model view and controller as being different layers (View sits on top of
controller sits on top of model)…
The goal in MVC is for models to be completely non-dependent from views,
and making it possible to have different views against the same model.
Yes, views are essentially what the user sees…
The best way to understand the interaction, and responsibilities is to
consider what happens when a user makes a request… Let’s say you’ve
done scaffolding properly on a User, you could implement a User_Admin
controller, and to edit an existing User entry, you would follow a link
(let’s assume you’ve done all of the following basic steps which you
generally need to do when creating any new rails app:
- edit config\database.yml
- ruby script\generate model
- edit auto-generated migration in db\migration
- run ‘rake migrate’
- create controllers using a syntax like:
ruby script\generate controller MyController index find
7 create some views
- run ruby script\server to run your web app locally
- browse http://localhost:3000/<controller_name> to see your app
created a basic User model, updated the migration to create a table with
the right columns, run the migration, then created some basic
scaffolding, run WEBrick locally
What rails when the user makes the request is look for a controller with
the name of ‘user_admin’, then within this controller, the action
Let’s say you had the User_Admin_Controller controller class with the
action edit, who’s job is to retrieve a user to be edited, you’d
probably want code that looks like this (scaffolding writes this for
class User_Admin_Controller < ApplicationController
@user = User.find(params[:id]) # retrieve the user with the given ID
from the model
So in the controller, we use the User ActiveRecord to get a User object.
Note that models can be plain old classes, they don’t have to be
ActiveRecord classes. The advantage of an ActiveRecord class in Rails
is that it is very easy to save their state to a database.
After the controller action is invoked, rails then tries to find a view
with the same name as the action (in this case, it would look in
When you initialize instance variables in controllers, like @user = …
or @welcome_string = “hello there”, in views you can display those
values using the notation <%= @user %> or <%= welcome_string %>… The
view’s job then becomes about displaying the appropriate data obtained
from the controller, and to also make it possible for the user to
further interact with your application (more links, buttons, etc)
Hope this helps!!!
Michael Wisniewski wrote:
I am very new to Ruby on Rails; I just started this week and I'm
struggling to try to understand it. I’ve read the LAMP tutorial along
Amy’s, and started reading the Agile Web D. book.
I am having some problems though. First off, I am very (still)
about Models, Views, and Controllers. From my understanding, views are
the end user sees. Models do database stuff and Controllers is the
between Views and Models. Basically, it tells the database to import
check/validate data, etc. Am I on the right path so far?
When creating a Rails app, you run 'ruby script/generate
The something being either model, controller, or scaffold. How do you
which one to run? Is there one that just creates all three (model,
I'm sure I'm going to have a bunch more questions later, but I just
need a little kick to start going first.
View my blog!