rails チュートリアル7章(2周目)メモ

英語でrails tutorialを読み始めてから進みが一気に遅くなりpythonとRに逃げてました。効率が悪すぎたので日本語版に戻します。以下復習を兼ねたメモ。

まずはrestアーキテクチャについて。だいぶ忘れてましたが。簡単にいうと各ユーザーコンポーネントなどを一まとめにして指示を一括で出せるという感じかな。これがないと一人一人のユーザーに対してgetリクエストとかを指定しなくちゃいけなくて骨が折れるけど、リソース化してしまうことで自動生成されるidを読み取って指示を出してくれると。

コラム 2.2. REpresentational State Transfer (REST)
Rails関連の書籍を読んでいると “REST” という略語をよく見かけます。これはREpresentational State Transferの略です。RESTは、インターネットそのものやWebアプリケーションなどの、分散・ネットワーク化されたシステムやアプリケーションを構築するためのアーキテクチャのスタイルの1つです。REST理論そのものはかなり抽象的ですが、RailsアプリケーションにおけるRESTとは、アプリケーションを構成するコンポーネント (ユーザーやマイクロポストなど) を「リソース」としてモデル化することを指します。これらのリソースは、リレーショナルデータベースの作成/取得/更新/削除 (Create/Read/Update/Delete: CRUD) 操作と、4つの基本的なHTTP requestメソッド (POST/GET/PATCH/DELETE) の両方に対応しています。(HTTP requestメソッドの詳細については3.3で、具体的にはコラム 3.2で説明します)。

Rails開発者にとっては、RESTfulなスタイルを採用することで、作成すべきコントローラやアクションの決定が楽になります。作成(C)・取得(R)・更新(U)・削除(D)を行うリソースだけでアプリケーション全体を構成してしまうことすら可能です。ユーザーやマイクロポストなどに関しては自然にリソース化できるので問題ありません。第14章では、「ユーザーをフォローする」というやや複雑な課題について、REST理論を用いた自然で効率的なモデリングを披露します。

それ関連でHTTPメソッドも復習。先ほどのrestに出てきたhttpメソッド。restではCRUDに対応するとともに、HTTPリクエストメソッドにも対応していると。

コラム 3.2. GETやその他のHTTPメソッドについて
HTTP (HyperText Transfer Protocol) には4つの基本的な操作があり、それぞれGET、POST、PATCH、DELETEという4つの動詞に対応づけられています。クライアント (例えばFirefoxやSafariなどのWebブラウザ) とサーバー (ApacheやNginxなどのWebサーバー) は、上で述べた4つの基本操作を互いに認識できるようになっています (ローカル環境でRailsアプリケーションを開発しているときは、クライアントとサーバーが同じコンピュータ上で動いていますが、一般的には、それぞれ別のコンピュータで動作しているという点を理解しておいてください)。Railsを含む多くのWebフレームワークは、HTTPの各操作を発展させたRESTアーキテクチャの影響を受けています。第2章でも簡単に触れましたが、第7章ではより深い内容について学びます。

GETは最も頻繁に使われるHTTPリクエストで、主にWeb上のデータを読み取る (get) ときに使われます。「ページを取得する (get a page)」という意味のとおり、ブラウザはhttp://www.google.com/やhttp://www.wikipedia.org/などのWebサイトを開くたびにGETリクエストをサイトに送信します。POSTは、GETの次によく使用されるリクエストで、ページ上のフォームに入力した値を、ブラウザから送信する時に使われます。例えばRailsアプリケーションでは、POSTリクエストは何かを作成するときによく使われます (なお本来のHTTPでは、POSTを更新に使ってもよいとしています)。例えばユーザー登録フォームで新しいユーザーを作成するときは、POSTリクエストを送信します。他にも、PATCHと DELETEという2つの操作があり、それぞれサーバー上の何かを更新したり削除したりするときに使われます。これら2つの操作は、GETやPOSTほどは使われていません。これは、ブラウザがPATCHとDELETEをネイティブでは送信しないからです。しかし、Ruby on Railsなどの多くのWebフレームワークは、ブラウザがこれらの操作のリクエストを送信しているかのように見せかける技術 (偽装) を駆使して、PATCHとDELETEという操作を実現しています。結果として、Railsはこの4つのHTTPリクエスト (GET・POST・PATCH・DELETE) を全てサポートできるようになりました。

なるほど。次に出てくる表を見てみるとこのあとget “url”, to “controler#action”の記述自体をresources :users,で補完できるのかな?多分そうに違いない・・・。

これまた不覚にも忘れていた・・・、本当に毎日やらないと成長が止まってしまいますね。まず先ほどルーティングにresources :usersを書いたことでusers/1というurlにアクセスできるようにしました。しかし、users/1のurlの中身が空っぽなのでshow.html.erbというファイルを作りました。このファイルの中には

と記述しました。しかしこのまま実行してもエラーが出てしまいます。@userというのはインスタンス変数なので参照する場所が必要です。参照場所はusersコントローラのshowアクションの中になるのでusersコントローラにshowアクションを追加し、@userを定義しましょう、という流れ。で、showアクションに書くのがこれ、

Userモデルのfindメソッドを使うことによってデータベースからユーザーを取り出します。ここでparamsの役割ですが、

ユーザーのid読み出しにはparamsを使いました。Usersコントローラにリクエストが正常に送信されると、params[:id]の部分はユーザーidの1に置き換わります。つまり、この箇所は6.1.4で学んだfindメソッドの User.find(1)と同じになります。(技術的な補足: params[:id]は文字列型の “1” ですが、findメソッドでは自動的に整数型に変換されます)。

色々繋がりますね。最初にresources :userとしたことでusers/1というurlにアクセスできるようになった。つまり各ユーザをidごとにurl分けられるようになった。そうするとusers/:idの:idのところには常にuseridが代入されてる状態になる。先ほどのfindメソッドではこれを利用して、params[:id]とすることでこの[:id]に1を代入していたのですね。

次は画像の挿入について。ここではgravatorというサービスを利用するそうなのですが、gravator_forというヘルパーメソッドを使います。このヘルパーメソッドはいつでもどこでもビューで自動的に利用できるのですが、今回はuser関連のヘルパーにgravator_forメソッドを定義します。

form_forについて。form_forの直後、do |f|で@userの属性を設定するために特別に設計されたHTMLを返してくれるみたい。なので以下のコードは

ラベル付きテキストフィールドを返していて、実際のHTMLコードをみてみると・・・

こういうHTMLを返してくる。

Railsはnameの値を使って、初期化したハッシュを (params変数経由で) 構成します。このハッシュは、入力された値に基づいてユーザーを作成するときに使われます (詳しくは7.3で説明)

これだけだといまいちですね。7,3に期待。

次に重要な要素は、formタグ自身です。Railsはformタグを作成するときに@userオブジェクトを使います。すべてのRubyオブジェクトは自分のクラスを知っている (4.4.1) ので、Railsは@userのクラスがUserであることを認識します。また、@userは新しいユーザーなので、 Railsはpostメソッドを使ってフォームを構築すべきだと判断します。なお、新しいオブジェクトを作成するために必要なHTTPリクエストはPOSTなので、このメソッドはRESTfulアーキテクチャとして正しいリクエストになります (コラム 3.2)。

Rails賢いな・・・。流れ的には、@userが新しいユーザー→postメソッド使ってフォーム構築となるので、HTMLは以下のようになる。

ちゃんとmethod=postが指定されています。

7.1.2で、resources :usersをroutes.rbファイルに追加すると (リスト 7.3) 自動的にRailsアプリケーションが表 7.1のRESTful URI に応答するようになったことを思い出してください。特に、/usersへのPOSTリクエストはcreateアクションに送られます。

これめちゃくちゃすごいと思うんですよね。最初にresources :usersを追加したことで/usersへの全てのアクションとHTMLリクエストが対応可能になり、さきほど述べたように@userが新しいユーザーなのでpostメソッドを使ってフォームを構築、postメソッドはcreateアクションに紐づいているのでuserコントローラのcreateアクションに反映される。

railsに名前などを入力して送信するとパラメーターハッシュが生成されます。以下のようなのが表示されるはず

このハッシュがUsersコントローラにparamsとして渡される。さらにいうと、このハッシュのnameとかemailが先ほど述べたhtmlのinputタグの属性の値になっている。

続いてエラーメッセージの表示について。そもそもパーシャルってなんだっけ?となってしまった・・。パーシャルは簡単にいうとコード長くしたくないから別の場所に分けて保存してrenderメソッド使って呼び出そうってやつだった。今気づいたけどrenderって「描画」って意味なのか。

またまたrailsの賢さを発見。新しいユーザーを作成した後、その新規ユーザーのページにリダイレクトするときのコード、

これの意味するところは、

これらしい。指示を与えなくても意味を読み取ってくれるみたい。

一応曖昧だった知識はこんな感じです。7章結構時間がかかって、いかに1周目の時に飛ばし飛ばしやりながらだったのか実感しました。二周目で割と理解できましたが、自分でアプリを作っていく時にもrailsチュートリアル3周目やりつつって感じになりそうだなあと思いました。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする