DEV Community

Alexander Rovang
Alexander Rovang

Posted on

Notes to Myself (Rails:Entry#1a - Routes)

Client's Journey

I think the first major step in understanding the Rails framework is to break down how Routes, Controllers, Route Helpers, and Views all interact with one another.

Up till now we've spent quite a bit of time contemplating C.R.U.D. functionality ("Create", "Read", "Update", "Delete") and the 7 RESTful routes (index, new, create, show, edit, update, delete).

I'd like to reorganize these concepts into a flowchart I'm calling the "Client's Journey" which will trace the steps a program must take to render one of the 4 possible views a user could see.

The first split-point of the Journey could be phrased this way -

 "Do I want to see something, or do I want to change something?"
Enter fullscreen mode Exit fullscreen mode

Beginning with the path of "seeing" there are two primary routes available. 1) You can see many things, or 2) you can see a single thing. Choosing to "see" a grouping of many similar things is the simplest route available in Rails. When the Client types a URL into their browser, three things happen:

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/index.html.erb

The Client's Journey begins in the routes.rb file, where the program checks for the availability of the URL path. If the routes.rb file has been set up with a "resources" method...

Rails.application.routes.draw do
  resources :movies
end
Enter fullscreen mode Exit fullscreen mode

...then the Client will be redirected to the appropriate controller with a GET request in the index method. Resources, in its unfiltered form, produces all seven of the RESTful routes for whatever controller you have specified. It can also be configured (via only: or except:) to limit which routes are available.

class MoviesController < ApplicationController
  def index
    @movies = Movie.all
  end
end
Enter fullscreen mode Exit fullscreen mode

In Rails, the index method implicitly calls the index.html.erb view from the sub-folder in views that has the same name as the model (in this case, "movie"). Note that both the model and the view sub-folder are the singular form of the controller class name. Typically the only information needed in the index method is an instance variable that stores all instances of a particular class, which can then be accessed in the view.

Once there, it renders any information the programmer has allowed to be seen.

<h1>Movies#index</h1>
<p><% @movies.each do |movie|%></p>
<div class="box">
<p>Name: <%= movie.name %></p>
<p>Year: <%= movie.year %></p>
<p>Genre: <%= movie.genre %></p>
<p>Director: <%= movie.director %></p>
</div>
<% end %>
Enter fullscreen mode Exit fullscreen mode

The other path out of the "seeing" option is to see a single thing. This is called the "show" method in the controller, and has a similarly named view file. The Client's Journey to the show.html.view file would look like this:

1) config/routes.rb
2) app/controllers/movies_controller.rb
3) app/views/movie/show.html.erb

As you can see, it's identical to the index method in terms of sequence.

The change occurs in the controller where instead of the index method, the Client is directed to the show method.

  def show
    @movie = Movie.find(params[:id])
  end
Enter fullscreen mode Exit fullscreen mode

Again, an instance variable needs to be set in order to access information on the view page, but here we only gather information about a single object via it's id.

From there we are implicitly guided to the appropriate view, show.html.erb...

<h1>Movies#show</h1>

<div>
<p>Name: <%= @movie.name %></p>
<p>Year: <%= @movie.year %></p>
<p>Genre: <%= @movie.genre %></p>
<p>Director: <%= @movie.director %></p>
</div>
Enter fullscreen mode Exit fullscreen mode

..which really only differs from the index view by lack of an iteration method.

In the next post I'll address the other side of the Client's Journey: The "change".

Top comments (0)