あしあと

明日の自分への情報発信

Railsの学習(4日目)

rails4日目

 

削除機能を作る

ootingはpostから始める。URLから削除したい投稿を指定できるように、「posts/:id/destroy」とする。このURLにidを含める考え方は合理的で大事だね。

f:id:keropp1234:20200119064954p:plain

 

postとgetの違いとは?

違いは画像の通り。destroyは投稿データを削除し、更新するのでデータベースを変更していることになり、post rootingになる

f:id:keropp1234:20200119065150p:plain

 

destroyアクションのリンクを作る際、今まで通りに作るとpostアクションを探してしまう。

f:id:keropp1234:20200119065445p:plain

そのため、link_toの第3引数に「{method: "post"}」を追加することで、「post」として定義されているルーティングにマッチするようになる。

f:id:keropp1234:20200119065457p:plain

 

destroyアクション内で行う処理は以下のとおり

f:id:keropp1234:20200119065710p:plain

 

投稿の制限をする

空白の投稿を制限する。

f:id:keropp1234:20200119180739p:plain

 

不正な投稿内容が投稿されないようにチェックする仕組みをValidation(検証、実証、認可、妥当性)という。これに引っかかるとデータベースに保存がされなくなる。

f:id:keropp1234:20200119180958p:plain

 

Validationは図のようにモデルとして設定する。validates」を用いてカラム名と内容を指定します。図のように{presence: true}を用いることで、「そのカラムの値が存在するかどうか」をチェックすることができます。右の画像はvalidates(検証) :content(検証するカラム名), {presence(存在感):true}で空の投稿がないかどうか検証する、となっている。

f:id:keropp1234:20200119181205p:plain

 

validationの詳細な指定

validationでは値が存在しているか否かだけでなく、文字数も設定できる。

図のように「length」を用い、{maximum: 数値}を指定することで、最大文字数を設定することができます。下の画像では文字の長さ、という意味になる。

f:id:keropp1234:20200119181825p:plain

 

validationで検証する内容はハッシュとなっているため、図のようにコンマで区切ることで複数の内容を検証することができる。

f:id:keropp1234:20200119182118p:plain

 

 

validationに引っ掛かったらもう一度入力フォームに戻る処理を行う。これにはsaveメソッドに真偽値を用いることで、validationに引っ掛かったパターンと引っかからなかったパターンを想定することができる。

 

例えば保存に成功したパターンをtrue, 失敗したパターンをfalseとそれぞれ返すようにするとして、rails consoleで試すと以下のようになる。

f:id:keropp1234:20200119182549p:plain

 

バリデーションの結果で表示するページを変える。

例えば投稿成功なら投稿一覧のページへ、失敗なら再度投稿フォームへ、というふうに設定してみる。

f:id:keropp1234:20200119201634p:plain

 

投稿できなかったときは投稿編集ページに飛ぶ(リダイレクトする)ようにする。保存できたときは投稿一覧ページへ飛ぶようにする。これをif文で条件分岐することで成立させる。

f:id:keropp1234:20200119201707p:plain

 

直前の内容を表示したまま編集ページに戻る

そもそもなぜ投稿した内容が消えてしまうのか?それは

①updateアクションでは失敗したときにeditアクションに転送しており、編集画面にリダイレクトするようになっている。

②さらにeditアクションはデータベースから編集前のデータを取得している。

③フォームの初期値は②で取得したデータにになるよう指定されている。

f:id:keropp1234:20200119202546p:plain

 

そしてupdateアクションの中の「params[:content]」にはpost.contentに代入するための、直前の投稿内容が入っているため、これを編集画面で呼び出すようにすれば良い。

f:id:keropp1234:20200119203004p:plain

 

そこで、render(差し出す)メソッドを用いることでeditアクションを経由せず、直接編集画面に表示できるようになる。

差出先は、render("フォルダ名/ファイル名")のように表示したいビューを指定する。
renderメソッドを使うと、redirect_toメソッドを使った場合と違い、そのアクション内で定義した@変数をビューでそのまま使うことがでる。プログラムの命令がどのようなルートで実行されているか、柔軟で有機的に捉えないといけないね。

f:id:keropp1234:20200119203316p:plain

 

このままだとユーザーに分かりづらいので、エラ〜メッセージが出るようにする。

rails consoleで流れを見てみると、保存失敗前には@post.errors.full_messagesの中に空の配列が入っており、失敗後にのなかにエラ〜メッセージが入っているのがわかる。

f:id:keropp1234:20200120073346p:plain


それをedit.html.erbのフォームの上で、each文を用いてエラー文を1つずつ表示するようにする。

f:id:keropp1234:20200120073556p:plain

 

サクセスメッセージの表示

ページに一度だけ表示されるメッセージをフラッシュという。

Railsではフラッシュを表示するために、特殊な変数flashが用意されている。アクションで変数flash[:notice]に文字列を代入すると、flash[:notice]をビューで使うことができます。変数flashは1度表示された後に自動で削除されるようになっています。flashはいろいろな箇所で共通で使っていくのでapplication.html.erbで表示しましょう。

下の画像で言えば、if文があるので、もしセーブしたら、表示したい文字列をフラッシュとして表示する、という意味である。

f:id:keropp1234:20200120075058p:plain