Analyzing the Rails Process: Routing with Resources
In this guide you'll learn how the Resource system works with Rails in relation to routes.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

Now that we have analyzed the controller that the scaffold created for us, you may wonder, if you where to write the code yourself, if you would follow the same process. The answer is sometimes.

The words found in the controller: index, show, new, edit, create, update, and destroy are special reserved words that are used because of the underlying routing system in rails.

Open the file called routes.rb, and you should see this:

large

There is a lot of power in the coderesources :blogs . We need routes for all the different actions like create, edit, update and destroy, yet there's only a single line of code here.

Let’s take a look at how we get all those routes out of the single word resources.

Rake Routes

Open your terminal. Go ahead and stop the rails server if it is currently running. Next make sure you are at the root of your directory. You can verify this by typing the command ls into your terminal. You should see the gemfile, app, config, db. etc… directories (cd into the root of your application if needed).

Once you are at the root of your project type the command: rake routes

large

You can see the list of routes here. All these routes were created by a single word because resources is a special word in Rails that encapsulates all of the popular routes applications use. The words index, edit, create, etc in our controller, are also special words and special processes because they are all part of restful routing. Restful routing means that there are specific standardized names for our routes - resources contains all of them.

If you look at the routes listed you can see you have a route for each key word in our controller (index, create, new, edit, show, update, & destroy).

When we build out our app, we're going to have hundreds of routes. The best way to know the purpose of a route is by looking at the information the rake routes command gives us.

Garnering Info

Let’s look at the last column first. That is the Controller#Action column. The first route in the list is looks like this: blogs#index. That means it is associated with our Blogs controller and our index action.

The URI Pattern provides the information we would type into the browser to access the associated page. So here, we see /blogs is mapped to the blogs index page.

The Prefix gives us special methods that are auto-generated by Rails. It is named prefix because it is the shorted form of the method name to call a path. The first prefix we have is titled blogs. It is therefore short for blogs_path. This method will call the index action path. So, if we put blogs_path as a link in one of our views, it will take us to the /blogs URI in our browser, which will display the blogs index page.

Some of the actions don't have a prefix. It's okay that they do not have the method calls because you don't want to have routes for them. For example, create and update happen behind the scenes, so there is no direct path associate with them. However you can see new_blog_path would take you to the /blogs/new URI which is mapped to the blogs#new action. So this would take you to the form page where you could add the elements of your new blog.

Routing is pretty complex so we will be visiting the topic in other guides as well so you can become very familiar with the process.

I want to cover one last thing in this guide. If you look at the URI Pattern. Some of them have :id. This means that URI is expecting the blog id. For example, if we want to edit the blog with an id of 3, then the URI will be /blogs/3/edit.

We can test this in the browser. Start the rails server again with the command rails s.

Go to the browser and hit refresh. Now click edit on one of your blog posts.

large

You will see the id of each blog in the URL address. The id also appears in the URL address when you click show.

The routing system has set the parameters and items, and it knows when to look for what type of route based on the action that is being taken. This is all bundled up nicely for us in the Rails routing system.

Technically, you can build all this from scratch. However, there will probably come a time when you want to implement a custom action. In that case, you can’t simply use resources. You will have to put the custom actions in place. We will do this later on in the course.