What's the Purpose of Controllers in Rails?
A guide for walking through the goal for controllers in a Ruby on Rails application, including how this practically applies to working with data flow in an application.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

In this lesson, we are going to talk about controllers and their purpose.

To start, let's open our controller file projects_controller.rb In this file, you can see there are many different actions such as create, update and delete. Now, if you look right at the top, you can see that ProjectsController is a Ruby class that is inheriting from ApplicationController. If you've never used object-oriented programming, this means ProjectsController is going to use everything contained inside ApplicationController.

If you're wondering what an ApplicationController is, let's go to application_controller.rb.

large

If you see, ApplicationController class inherits from ActionController::Base - a module inside of Rails that has a bunch of different built-in methods. You can also put whatever you want inside this ApplicationController file, so that other controllers that inherit from it have access to this code. For example, I add a method here.

def foo
  p "Hey from the application controller"
end

This method is available to all controllers like projects_controller.rb and pages_controller.rb that inherit from this class.

Now that you've understand the hierarchy, let's go back to the projects_controller. rb file. If you see the second line, you can see something called before_action. As the name implies, this code will run before each of the methods contained in the list.

This code calls the private set_project method located right at the bottom, only before the methods show, edit, update and destroy. It will not call set_project before the index method contained in the file. So, you have some control here on how you want the application to flow.

If you go the set_project method, you can see that it creates an instance variable project, finds the corresponding record with a parameter id, and stores this value in the variable. Here, the id parameter comes from the browser as a part of the http get function.

In other words, if you go the browser and click on the Show link of project 6, this value gets passed to the set_project method. In turn, this method queries the database for record #6, stores it in the project variable and displays it in the browser for us.

You can check this workflow by going to the show.html.erb file, where the instance variable project is called.

Now, what happens if you don't have the before_action call? You would have to type the code contained in the set_project method into other methods, and this duplicates the code unnecessarily.

Now that we know what a controller is, let's look at its purpose. Primarily, a controller:

  • Allows view files to access data elements. For example, view files access the `projects' variable to pass data, and this is possible only because of the controller files.

  • Handles data flow

I hope this gives you a good idea of what controllers are and we'll now start looking into how we can further work with controllers to build out the application.