over 2 years ago

複習一下git步驟:(最後一步別忘記)

$ git init
$ git add -A
$ git commit -m "Initialize repository"
create a new repository
$ git remote add origin git@bitbucket.org:<username>/toy_app.git
$ git push -u origin --all # pushes up the repo and its refs for the first time
$ git commit -am "Add hello"
$ heroku create
$ git push heroku master
$ git status
$ git add -A
$ git commit -m "Finish toy app"
$ git push
$ git push heroku
$ heroku run rake db:migrate

摘要:
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:

    $ rails generate scaffold User name:string email:string
    
  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):

    $ bundle exec rake db:migrate
    ==  CreateUsers: migrating ====================================================
    -- create_table(:users)
    -> 0.0017s
    ==  CreateUsers: migrated (0.0018s) ===========================================
    This simply updates the database with our new users data model. (We’ll learn more about database migrations starting in Section 6.1.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.

    HTTP request
    URL
    Action
    Purpose
    GET
    /users
    index
    page to list all users
    GET
    /users/1
    show
    page to show user with id 1
    GET
    /users/new
    new
    page to make a new user
    POST
    /users
    create
    create a new user
    GET
    /users/1/edit
    edit
    page to edit user with id 1
    PATCH
    /users/1
    update
    update user with id 1
    DELETE
    /users/1
    destroy
    delete user with id 1
    Table 2.2: RESTful routes provided by the Users resource in Listing 2.2.
    
  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.

app/models/user.rb
class User < ActiveRecord::Base
  has_many :microposts
end

Listing 2.12: A micropost belongs to a user.

app/models/micropost.rb
class Micropost < ActiveRecord::Base
  belongs_to :user
  validates :content, length: { maximum: 140 }
end

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:

$ 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
← ROR TUTORIAL (3RD ED.) Ch1 From zero to deploy Rails Guide - Association →