over 2 years ago

## ROR TUTORIAL (3RD ED.) Ch2 A toy app

rails generate scaffold Micropost content:text user_id:integer
bundle exec rake db:migrate
2.3.2：validations是放在model裡面，限制某個column (attribute)的屬性
2.3.3：has_manybelongs_to

2.3.4： Inheritance hierarchies

$git push heroku之後，記得要$ heroku run rake db:migrate

1. Now we’re ready to start making the app itself. The typical first step when making a web application is to create a data model, which is a representation of the structures needed by our application.
In our case, the toy app will be a microblog, with only users and short (micro)posts. Thus, we’ll begin with a model for users of the app (Section 2.1.1), and then we’ll add a model for microposts (Section 2.1.2).

2. Rails scaffolding is generated by passing the scaffold command to the rails generate script. The argument of the scaffold command is the singular version of the resource name (in this case, User), together with optional parameters for the data model’s attributes:

3. (Note that there is no need to include a parameter for id; it is created automatically by Rails for use as the primary key in the database.)

4. To proceed with the toy application, we first need to migrate the database using Rake(Box 2.1):

5. Note that, in order to ensure that the command uses the version of Rake corresponding to our Gemfile, we need to run rake using bundle exec. On many systems, including the cloud IDE, you can omit bundle exec, but it is necessary on some systems, so I’ll include it for completeness.

6. 2.2.2 MVC in action

7. You may notice that there are more actions than there are pages; the index, show, new, and edit actions all correspond to pages from Section 2.2.1, but there are additional create,update, and destroy actions as well. These actions don’t typically render pages (although they can); instead, their main purpose is to modify information about users in the database.

8. Note fromTable 2.2 that there is some overlap in the URLs; for example, both the user show action and the update action correspond to the URL /users/1. The difference between them is the HTTP request method they respond to.

9. This index action has the line @users = User.all (Step 3 in Figure 2.11), which asks the User model to retrieve a list of all the users from the database (Step 4), and then places them in the variable @users (pronounced “at-users”) (Step 5). The User model itself appears inListing 2.6; although it is rather plain, it comes equipped with a large amount of functionality because of inheritance (Section 2.3.4 and Section 4.4). In particular, by using the Rails library called Active Record, the code in Listing 2.6 arranges for User.all to return all the users in the database.

10. Once the @users variable is defined, the controller calls the view (Step 6), shown inListing 2.7. Variables that start with the @ sign, called instance variables, are automatically available in the views; in this case, the index.html.erb view in Listing 2.7 iterates through the @users list and outputs a line of HTML for each one. (Remember, you aren’t supposed to understand this code right now. It is shown only for purposes of illustration.)

11. 2.3.3 A user has_many microposts

One of the most powerful features of Rails is the ability to form associations between different data models. In the case of our User model, each user potentially has many microposts. We can express this in code by updating the User and Micropost models as inListing 2.11 and Listing 2.12.
Listing 2.11: A user has many microposts.

Listing 2.12: A micropost belongs to a user.

We can visualize the result of this association in Figure 2.15. Because of the user_id column in the microposts table, Rails (using Active Record) can infer the microposts associated with each user.

With the completion of the Microposts resource, now is a good time to push the repository up to Bitbucket:

$git status$ git add -A
$git commit -m "Finish toy app"$ git push
Ordinarily, you should make smaller, more frequent commits, but for the purposes of this chapter a single big commit at the end is fine.

At this point, you can also deploy the toy app to Heroku as in Section 1.5:

$git push heroku (This assumes you created the Heroku app in Section 2.1. Otherwise, you should run heroku create and then git push heroku master.) To get the application’s database to work, you’ll also have to migrate the production database:$ heroku run rake db:migrate

1. Inheritance hierarchies

MicropostsController < ApplicationController < ActionController::Base

1. 2.3.5 Deploying the toy app

With the completion of the Microposts resource, now is a good time to push the repository up to Bitbucket:

Ordinarily, you should make smaller, more frequent commits, but for the purposes of this chapter a single big commit at the end is fine.

At this point, you can also deploy the toy app to Heroku as in Section 1.5:

(This assumes you created the Heroku app in Section 2.1. Otherwise, you should run heroku create and then git push heroku master.)

To get the application’s database to work, you’ll also have to migrate the production database: