Day 4: Models, Controllers and Routing

Task model

Rails has a particular file structure. Models are located under app/models folder. Controllers are under app/controllers. Views are under app/views. We need to edit our Task model. Let’s open it. It’s under app/models/task.rb.

Task Model

When you add a new database column, Rails does one very useful thing for you. It generates attribute methods. A name of every attribute method is the same as a corresponding column’s name. An attribute method returns a value of a corresponding row in a database. Rails defines several attribute methods. One for each database column.

As a user of our application, we need to know when a task is completed. Let’s see how completed attribute method helps us to achieve this goal. We will try it in rails console. Open up your terminal and navigate to the project’s directory. Type bundle exec rails console. It will start a new IRB session within the context of our todo app.

$ bundle exec rails console
Loading development environment (Rails 4.0.2)
>> task =
=> #<Task id: nil, name: nil, created_at: nil, updated_at: nil, completed: nil>
>> task.completed?
=> false
>> task.completed = true
=> true
>> task.completed?
=> true

_Note: Did you notice a question mark at the end of the function’s name? This is another Ruby convention. Question mark methods return true or false. It’s like asking a question: “Hey task, are you completed?” _

Four things happened here:

  1. We instantiated a new Task object.
  2. We called completed? method on the task object. Since completed field is nil, it returned false.
  3. Now we decided to complete a task. We’ve changed completed attribute to true
  4. Is our task.completed? Yes, it finally is.

Note: nil is a Ruby builtin data type. It represents nothing. In other words, it’s the absence of data.


Controller’s job is to control a workflow. If you look at “How Rails Works” diagram, the controller is displayed in the center. It’s like a manager. It directs others and delegates actual work to it’s close friends: Models and Views.

If you open up app/controllers/tasks_controller.rb you will see a lot of generated code. This is what scaffold generated for us automatically. Let’s take a look.

Controller action

There are 3 main things:

  1. TasksController inherits from ApplicationController.
  2. Every method represents an action. Look at the comments before each action. These are hints. For example: if you send a get request to /tasks/1 then the show action gets triggered.
  3. Method before_action sets up a filter. Filter is a method that gets executed before, after or around a specific action. In our case, the method set_task is executed before actions show, edit, update and destroy.

Note: Code comment is any code prefixed by a pound sign #. Code comments are not executed by an interpreter. They are used mostly as hints for developers.

Thanks to set_task before filter, we don’t need to manually retrieve our task from the database every time the action is called.


You probably wonder how Rails determines what action corresponds to what url. It figures it our from the set of rules called routes. Routes are defined in the file config/routes.rb. Since we’re here, let’s add the root route for our todo application. Default welcome page is nice, but we want to see a list of tasks instead of it.

Home route

Go back to your browser. Let’s go to http://localhost:3000. This time we should see task listing page instead of welcome page.

Home page with a listing

What happened here?

We looked at Tasks model. We played with attribute methods in rails console. We understood the structure of TasksController. After that we dove into config/routes.rb file and added a root route.

Ready to make more changes to your rails app? Let’s move on to our views.

Photo by MaZzuk