Toyアプリケーション
第2章まで疑問を持たずに途中までいき、第1章で得た知識で進もうとしてうまくいかなくて困ってたことがラストまでいってわかりました。
ユーザーページ
検索する
既に各ページは作成されているので、URLを指示すれば表示される。
URL | アクション | 用途 |
---|---|---|
/users | index | すべてのユーザーを一覧するページ |
/users/1 | show | id=1のユーザーを表示するページ |
/users/new | new | 新規ユーザーを作成するページ |
/users/1/edit | edit | id=1のユーザーを編集するページ |
素敵だわ。ここまでが既に作成されているわけで。
まぁDBに登録してなきゃまだid=1
は表示されないけどね。
まず、/users
で一覧を確認して何もない状態を確認したらNew User
をクリックすれば、/new
に遷移してくれるわけで。
便利だわ。
まぁ表示されているボタンをクリックすれば該当するページを勝手に表示して編集もするし、削除もするし。
一覧表示もするし。
いいわぁ〜。
MVCの挙動
たぶん、ここが一番のキモなんでしょうね。
ここはちゃんと覚えなきゃと思います。
そうしないと修正するファイルがわからない状態になっちゃう。
で、ルールがあるらしい。
Railsルートで使うUsersリソース用のルール
ルートからusersへのルーティングを追加する
config/routes.rb
Rails.application.routes.draw do resources :users root 'application#index' end
Usersリソースが提供するRESTfulなルート
HTTPリクエスト | URL | アクション | 用途 |
---|---|---|---|
GET | /users | index | すべてのユーザーを一覧するページ |
GET | /users/1 | show | id=1のユーザーを表示するページ |
GET | /users/new | new | 新規ユーザーを作成するページ |
POST | /users | create | ユーザーを作成するアクション |
GET | /users/1/edit | edit | id=1のユーザーを編集するページ |
PATCH | /users/1 | update | id=1のユーザーを更新するアクション |
DELETE | /users/1 | destroy | id=1のユーザーを削除するアクション |
Usersコントローラの骨格
app/controllers/users_controller.rb
class UsersController < ApplicationController def index end def show end def new end def edit end def create end def update end def destroy end end
Toyアプリケーションの簡潔なユーザーindexアクション
app/controllers/users_controller.rb
class UsersController < ApplicationController . . . def index @users = User.all end . . . end
ToyアプリケーションのUserモデル
app/models/user.rb
class User < ApplicationRecord end
indexアクションに対応しているビュー
app/views/users/index.html.erb
<h1>Listing users</h1> <table> <thead> <tr> <th>Name</th> <th>Email</th> <th colspan="3"></th> </tr> </thead> <% @users.each do |user| %> <tr> <td><%= user.name %></td> <td><%= user.email %></td> <td><%= link_to 'Show', user %></td> <td><%= link_to 'Edit', edit_user_path(user) %></td> <td><%= link_to 'Destroy', user, method: :delete, data: { confirm: 'Are you sure?' } %></td> </tr> <% end %> </table> <br> <%= link_to 'New User', new_user_path %>
Micropostsリソース
マイクロポストを探検する
データモデルの実装
$ rails generate scaffold Micropost content:text user_id:integer
新しいデータモデルでデータベースを更新する
$ rails db:migrate
Railsルートで使うMicropostsリソース用のルール
config/routes.rb
Rails.application.routes.draw do resources :microposts resources :users root 'users#index' end
Micropostsリソースが提供するRESTfulなルート
HTTPリクエスト | URL | アクション | 用途 |
---|---|---|---|
GET | /microposts | index | すべてのマイクロポストを一覧するページ |
GET | /microposts/1 | show | id=1のマイクロポストを表示するページ |
GET | /microposts/new | new | マイクロポストを新規作成するページ |
POST | /microposts | create | マイクロポストを新規作成するアクション |
GET | /microposts/1/edit | edit | id=1のマイクロポストを編集するページ |
PATCH | /microposts/1 | update | id=1のマイクロポストを更新するアクション |
DELETE | /microposts/1 | destroy | id=1のマイクロポストを削除するアクション |
Micropostsコントローラの骨格
app/controllers/microposts_controller.rb
class MicropostsController < ApplicationController def index end def show end def new end def edit end def create end def update end def destroy end end
マイクロポストの最大文字数を140文字に制限する
app/models/micropost.rb
class Micropost < ApplicationRecord validates :content, length: { maximum: 140 } end
マイクロポストのコンテンツが存在しているかどうかの確認
app/models/micropost.rb
class Micropost < ApplicationRecord validates :content, length: { maximum: 140 },presence: true end
ユーザーとマイクロソフトの関連付け
1人のユーザーに複数のマイクロポストがある。
app/models/user.rb
class User < ApplicationRecord has_many :microposts end
1つのマイクロポストは1人のユーザーにのみ属する。
app/models/micropost.rb
class Micropost < ApplicationRecord belongs_to :user validates :content, length: { maximum: 140 },presence: true end
Userモデルに存在性のバリデーションを追加する
app/models/user.rb
class User < ApplicationRecord has_many :microposts validates name, presence: true validates email, presence: true end
アプリケーションをデプロイする
$ git status $ git add -A $ git commit -m "Finish toy app" $ git push
Herokuへの展開
$ git push heroku
アプリケーションのデータベースを動作させるためには、次のheroku runコマンドを実行して本番データベースのマイグレーションを行う必要もあります
これが大切でした。これは初めて出てきたのよ。
$ heroku run rails db:migrate
これをしなかったから思うような動作じゃなかったってことでした。
このコマンドを実行すると、先ほど定義したユーザーとマイクロポストのデータモデルを使って、Heroku上のデータベースが更新されます。マイグレーションが完了すれば、Toyアプリを実際のPostgreSQLデータベースをバックエンドに配置した本番環境で利用できるようになっているはずです
第2章はこれで終わり。
まぁベースとなる知識が盛り込まれた内容で、このまま終わりになれるレベルじゃないんだけど、最初の1歩でしょうか。