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
like this
http://localhost:3000/user_admin/edit/1
(let’s assume you’ve done all of the following basic steps which you
generally need to do when creating any new rails app:
- rails
- 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
running
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
‘edit’.
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
you)
class User_Admin_Controller < ApplicationController
def edit
@user = User.find(params[:id]) # retrieve the user with the given ID
from the model
end
end
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
/app/views/User_Admin/edit.rhtml)
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!!!
Dominique
Michael Wisniewski wrote:
Hi!
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
with
Amy’s, and started reading the Agile Web D. book.
I am having some problems though. First off, I am very (still)
confused
about Models, Views, and Controllers. From my understanding, views are
what
the end user sees. Models do database stuff and Controllers is the
space
between Views and Models. Basically, it tells the database to import
data,
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
know
which one to run? Is there one that just creates all three (model,
view,
and controller)?
I'm sure I'm going to have a bunch more questions later, but I just
need a little kick to start going first.
Thanks!
Mike
–
View my blog!
http://wiz561.blogspot.com/