(Giri) A local government employee in his twenties works on a Rails tutorial [Chapter 2]

Premise

・ Rails tutorial is the 4th edition ・ This study is the 3rd lap (2nd lap after Chapter 9) ・ The author is a beginner who has done all of Progate.

Basic policy

・ If you read it, you will not understand it. ・ Search and summarize terms that you do not understand (at the bottom of the article, glossary). ・ Dive into what you do not understand. ・ Work on all exercises. ・ Do not copy chords as much as possible.

Chapter 2 Let's get started ~

[2.2.1 Exercise for exploring user pages]

1. For readers who know CSS: Create a new user and use the HTML inspector function of your browser to check the "User was successfully created." Section. What happens when I reload the browser? → Start with F12. The contents of the id: notice p tag in the body disappear.

2. What happens if I try to enter only the name without entering the email? → You can register as a user. Maybe it's because validates isn't set in the User model.

3. What happens if I try to update by entering the wrong email address such as "@ example.com"? → This can also be updated. You need to enable regular expressions.

4. Try deleting the user created in the above exercise. What message does Rails display when I delete a user? → Display a flash message of User was successfully destroyed.

[2.2.2 MVC behavior exercise]

This is where the Users resource comes into routing. This didn't quite fit at first. I used to set routing one by one in Progate, what is this? ?? In short, it's like a standard that puts together the things that are used in a standard way. I understand that because I use it a lot, I can just say one word without writing the route one by one. The correspondence table of request-URL-action is summarized in Table 2.2. With a single word "resources: users", it will be automatically sorted to the corresponding action. It seems that it is RESTful. It would be easier to handle by linking the HTTP request and the database.

1. While referring to Figure 2.11, please draw a diagram of the behavior when accessing the URL / users / 1 / edit. → The figure below. For @user = ~~, the set_user method is specified in before_action in the controller, so the user with the corresponding id is acquired before edit.

2. While looking at the illustrated behavior, try to find the code that is getting the user information from the database in the code generated by Scaffold. → The index method of users_controller (@users = User.all) and the set_user method (@user = User.find (params [: id]))

3. What is the file name of the page for editing user information? → edit.html.erb in the views folder

[2.3.1 Exercise to explore the micropost]

1. For readers who know CSS: Create a new micropost and use your browser's HTML inspector feature to look up "Micropost was successfully created." What happens when I reload the browser? → Same as the exercise in 2.2.1

2. What happens when you try to create a micropost with both Content and User empty? → You can create it.

3. What happens if you try to create a micropost with a string of 141 characters or more entered in Content? (Hint: The first paragraph in the Ruby article on Wikipedia is just about 150 characters, but what happens? Do you?) → This can also be done.

4. Let's delete the micropost created in the above exercise. → Click Destroy on the / microposts page.

[2.3.2 Exercise to make a micro post micro]

1. Enter 141 characters or more in Content again, as you did in the 2.3.1.1 exercise earlier. How has the behavior changed? → An error page is displayed. 1 error prohibited this micropost from being saved: Content is too long (maximum is 140 characters)

2. For readers who know CSS: Use the HTML inspector function of your browser to check the displayed error message. → Yeah, well ... an error is displayed ...

[2.3.3 User has many micro posts Exercise]

Has_many and belongs_to came out in the association between data models. It will appear again after a long time. Is it time to make a post feed in Chapters 13-14? The user id and the microposts user_id are linked.

1. Edit the user's show page to see the user's first micropost. Try guessing the grammar from the other code in the file (this is where the technique introduced in column 1.1 comes into play). Let's go to / users / 1 to see if it looks good. → Is it like this?

rb:users/show.html.erb

<p>
  <strong>First post:</strong>
  <%= @user.microposts.first.content %>
</p>

2. Listing 2.16 is a validation that verifies whether the Micropost Content exists. Let's try it out to see if we can verify that the micropost is not empty (it looks like Figure 2.16 is successful). → Just add presence: true to validates. (Don't forget to separate with,)

3. Rewrite the FILL_IN part in Listing 2.17 and verify that the User model name and email exist (Fig. 2.17). → Enter: name and: email in FILL_IN.

[2.3.4 Inheritance hierarchy exercise]

"Since the Rails controller always inherits from ApplicationController, the rules defined in the Application controller are reflected in all the actions of the application." This is important. The method used by any controller is DRY if it is defined in the Application controller.

1. Open the application controller file and look for the code where the application controller inherits ActionController :: Base. →　class ApplicationController < ActionController::Base

2. Where is the code where ApplicationRecord inherits ActiveRecord :: Base? Try to find it by referring to the previous exercise. Tip: It's essentially the same mechanism as the controller, so if you look at the files in the app / models directory ...?) → In /app/models/application_record.rb, class ApplicationRecord <ActiveRecord :: Base

[2.3.5 Exercise for deploying applications]

1. Let's create a couple of users in a production environment.
2. Let's make a micro post for the first user in the production environment
3. Let's create a micropost with 141 characters or more entered in the content of the micropost. Check to see if the validations added in Listing 2.13 work well in production. → If all are done according to the tutorial, it will work normally.

Chapter 2 Summary

・ Overview of MVC model. It is important to write code while always keeping in mind the flow (because it will become more and more complicated in the future). -REST architecture: A structure that summarizes routine operations. It is easier to treat it as a resource as much as possible. -Validation can limit the contents of the input form. -Data models can be associated with each other.

From Chapter 3, we will finally work on full-scale web application development!

⇨ Go to Chapter 3! ⇦ Click here for Chapter 1 Click here for premise and author status for learning

A glossary that somehow captures the image

-HTTP Protocol (Hypertext Transfer Protocol) A communication convention used for sending and receiving between browser servers.

This time, I dealt with terms that are difficult to understand in the text, so this is all.