In the last guide Rails did a lot of work for us in a very short amount of time. We just ran one line of code, and we have the entire blog functionality in place including create, view, edit and delete options.

It’s pretty incredible to be able to harness the power of the scaffold, but let's take a step back and see what is going on behind the scenes. This is important because simply running the scaffold generator will limit what you can do in Rails. We will go through the entire file system, but I am going to break it down into several guides so you can take breaks as we explore all this information. This way you can develop a deeply ingrained understanding of how each piece works.

We will being in the app directory and take a look at what was created for us.

Assets

Open the app directory and navigate to the first folder, which is assets. If you click on it, there's a subfolder called config and inside that, a file called manifest.js.

Scaffold created a few things for us here. I'm not going to focus much on this. Rather, we'll spotlight the files that you can see have differences.

Javascripts

Let's jump to javascripts. When we created our blog feature, the file,blogs.coffee was generated. This file doesn’t have any code now because we don't have any custom scripts yet. Typically, coffee script allows us to do some really great integrations and we'll cover that later in the course. For now, remember that scaffolds created this empty file for us.

Stylesheets

The next folder is stylesheets. This is where the .css files are located. One of the files created for us was named blogs.scss. You might be wondering why this has an extension of .scss instead of .css . This indicates it is a Sassy style sheet, also known as Sassy css or sass. It is a pre-compiled version of CSS that allows you to do cool things like create variables, write code, and simply create css files more easily. The main thing to note here is that the scaffold generator created this file for us.

Another file that the scaffold generator created for us is scaffolds.scss. If you open this file, you will see it has quite a bit of content. This is the code that gave us the unattractive styling we saw on the browser. These styles are not meant for production. They are simply a way for us to see some kind of styling so we are not using HTML defaults. This is one of the reasons I do not keep this file.

Another reason I remove this file is that it can cause conflicts and lead to style bugs. It is best to just delete the code than have scaffold stylesheets override some of your other styling. We will implement all of our own styles later on in the project. So we can just delete it now.

Select every thing in the file and delete the code. Next, delete the scaffolds.scss file completely. (right click on the file and then choose delete). If you go to the browser now, you'll see the regular HTML formatting. We can close the assets folder for now.

Channels

The Channels directory is where we will write the code that will allow us to have live data in our application. Eventually we will use it to carry out the live chat feature for comments on our blogs. The scaffold didn’t add anything for us here, but I want you to be aware this directory has to do with action cable. Action cable gives us the ability to have an application that updates in realtime without use of the refresh button. This is a very cool feature of Rails 5.

Controllers

The controller directory is a very important one. The application controller was created when we built the app with the rails new command. This is the controller that all of our controllers will inherit from. It has some really clever behavior that we will cover later in the course.

The blogs controller, found in blogs_controller.rb was created from our scaffold. If you open the file you can see all the code that was written for us by the generator.

A controller gives you the ability to communicate directly between the model(where the data is), the view, and the routing system.

Controller Case Study with the Index Method

Open your browser window and go to “localhost:3000/blogs”.

When you type that URL in your browser address window and press enter, it hits the the index action in your controller. That means it runs the code inside the index method in your blogs controller.

For a clear understanding of how this works, let's create a new blog post. When you go back to the blog index page, you can see one post. Now create another blog post. When you return to the blogs index page you will see 2 blog items. These are the two blogs that have been created and stored in the database. When you go to /blogs in the browser, the index action is managing what is present in the display.

To test this action go to your blogs controller and change the index action (line 7) to:@blogs = Blog.limit(1) .

This code limits the database query so it only calls one blog. If you refresh the blog page in your browser, you'll see that it shows only one blog post, though two records are in the database.

It is important to realize there is a mapping between each method in the controller and what is displayed in the browser.

Change your index method to once again be @blogs = Blog.all

With that code you have indicated that the index method, should retrieve all the records from the database and make them available to the variable called @blogs. The view calls the index method and displays the variable value from @blogs in the browser window.

We will take a deeper dive into these methods but I want you to have this cursory knowledge of how they work.

Show Method

The show action might seem a little bit odd because if you look (beginning line 12) you can see it is an empty method.

You can access the show action in the browser window with the “Show” button. When you think of ‘show’, know it is when the browser takes you to a page with the details of that particular item. In this case it is showing you the details of your blog post.

If you look at the URL, you can see that the route in this case is showing blog/3 , yet there is doesn't seem to be anything in the method. So you may wonder how that id is being called.

We can find the answer on line 2 of the blogs_controller.rb file.

Line 2 contains the before_action. The before_action calls a method named set_blog, but only for the show, edit, update and destroy options.

Therefore, the set_blog method is getting called and executed in the show method automatically because of the before action.

Line 66 of the file is where you will find the set_blog method.

One way of looking at this is to imagine that the code in set_blog is in show because that's exactly what happens when you call the show method.

To test this out and have a little bit of fun, let’s add a line of code to the show method. Currently, the browser sends the ID of the blog, and based that id, the record is pulled up and displayed. What happens if we change the code to display the second record?

Add @blog = Blog.find(2) to your show method and save the file.

If you refresh your browser window, you will see that it displays the second blog record and not the third one. This is despite the fact that the URL still shows an id of 3. Obviously, this is not something you would want to do. So let’s take that line out of our show method.

Best Practices and the Before Action

It is a programming best practice to use the ‘before_action’. If we didn’t have it, we would have to duplicate the set_blog code in each of our show, update, edit, and destroy methods. Not only is it a bad practice to have duplicate code within your file like that, if you need to make a change to the code, you would have to change it it in every method.

In short, when you have identical code in a controller, it is best to place it inside a before action and then pass in the methods that it will be applied to.

In the next guide we will continue our study of the controller.