Project Ramon

A learning journey from a Ruby noob perspective

Rails Controllers: A Closer Glance

 

controllers1_header_imgI remember first hearing about about a need to better understand a controller and how an object is created, displayed, updated and destroyed from John Davison. After my insightful AirPair with Ryan Bigg, I am coming to realize where my understanding of an object’s life-cycle in relation to each  controller method could benefit from some growth.

Methods & Actions

Here’s an excerpt from the Rails Guides, its a great place to kick-off our walk-thru of controllers.

A controller is a Ruby class which inherits from ApplicationController and has methods just like any other class. When your application receives a request, the routing will determine which controller and action to run, then Rails creates an instance of that controller and runs the method with the same name as the action.

ApplicationController inherits from ActionController::Base, and since our all of our application’s controllers inherits from ApplicationController, we can use this one class to make site-wide controller configurations such as request forgery protection and filtering of sensitive request parameters.

Our controller actions, by default, are setup to render a template with a name that corresponds to the specific controller and action. It renders this view template after executing the code in the controller action.

Here’s a quick example of how this could look:

First lets set up a basic controller with action methods.

So lets say that we received a client request to look at a resource containing a list of all users. Rails routing will take this request and determine which controller and action is designed to handle this request, next, it will retrieve the data defined in the appropriate controller action, and select the proper template to render this resource back to the client.

Lets take a look at a visual that will describe an example of another client request in action.

Requests

controllers1_img1

Starting at the beginning of our example request journey, we’ll be making a client request of the view button. So lets assume we just clicked on ‘view’.

Once the button is selected Rails will determine the appropriate route for the request to take. Meaning that Rails routing will make a determination of which controller and action (i.e. teams#show in this case) should handle this request.

After that determination has been made, the code we wrote inside of teams_controller.rb line: 20 is executed which locates the associated template that comes by default in every controller action except create, update, and destroy. I should mention that a controller action will render a default template only if we have followed the naming conventions in our views file tree. The views are typically named index.html.erb, new.html.erb, edit.html.erb and show.html.erb. The template’s purpose is to shape how this resource looks once returned to the client. Here’s a link to a slideshare I found explaining this better.

Parameters

There are two types of parameters in Rails, and although they each come from different sources, a Rails params method contains both types in one hash. The query string parameters are everything after the question mark ? in a URL, and the second type of parameters are considered user created parameters. We can typically see this in our create action, where a POST request is committing attribute values from user populated form data set up by our ‘new’ template and action.

Responses Redirects and Renders

Every http request returns a response back to the client. Picking up where we left off in the paragraph on parameters, we can start to picture what our response will look like. Once our new user data initiates our instruction to commit the data, we can see in our users_controller example above on line: 12 that if our commit was a success then our application is directed to redirect_to @user.

redirect_to is an ActionController instance method that teleports the browser to the target URL specified in the options, which in this case is @user. The most explicit way I could think of re-writing this redirect_to would look like:

Thankfully, as the Rails Guides point out we can simplify with a little sugar, that looks something like:

controllers1_img2

I wanted to close by showing you my laters AirPair with Ryan, where he helps me dust the cobwebs out of my thinking as I get closer to completing my current project (yeah, I blew last Friday’s deadline but nearly done) sevendaysports.

Enjoy the video! It was a great experience for me.

Advertisements

Categories: AirPair, Newbie, Ruby on rails

Tags: , ,

4 replies

Trackbacks

  1. Rails Controllers (pt. 2): Sessions | Project Ramon
  2. Sevendaysports Lessons Learned | Project Ramon
  3. AirPair.com – What I’ve Learned pt. 2 | Project Ramon

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s