Rails – link_toの動的なスタイル

概要

Railsのヘルパーでクラスを動的に変更する方法。<%...%>を入れ子にすることができないが、文字列内の変数展開を使えば、変数の内容をクラスに設定できる。

コントローラー

コントローラーでインスタンス変数の配列を定義し、その内容によってlink_toのスタイルを変更する。

ビュー

インスタンス変数の配列の各要素を取り出しながら、

  • 変数availabilityenabled/disabledを設定
  • link_toのclass設定で変数availabilityを文字列展開

この結果、HTMLソースは以下の様になる。

スタイル

クラスに設定されるenabled/disabledに対してスタイルを設定する

実行結果

disableを設定したリンクの色が薄くなっている。また、このリンクを無効にしたので、クリックしてもコンソールに反応が出ない。

Rails – 掲示板 – 新規投稿機能

概要

新規投稿ページの枠組みをつくったので、これに投稿機能を実装する。

掲示板の第2段階へ

準備

投稿画像ディレクトリー

投稿画像ファイル保存用のディレクトリーを作成する。

public/post_images

ビュー

新規投稿のnewビューは再掲。

コントローラー

post_paramsヘルパー

ビューのフォームからパラメーターを受け取る際のヘルパーで、コントローラーで扱うパラメーターを許可している。

:upload_fileは直接保存しないので含めていない。

createアクション

フォーム入力を受けて投稿記事を生成・保存する本体。ファイルのアップロードについてはこちらを参照。

  • 記事を投稿したユーザーをデータベースから拾っている(L7)
  • メッセージか画像かどちらかがあれば投稿できる(L10-13)

app/controllers/posts_controllers.rb

メッセージと画像、メッセージのみ、画像のみの投稿後のデータベースの例は以下のとおり。

 

Rails – バリデーターのカスタマイズ

概要

モデルの検証を行うバリデーターを自作するのにいくつかの方法がある。

  • バリデーションメソッドをモデルで定義
  • ActiveModel::Validatorのサブクラスを定義
  • ActiveModel::EachValidatorのサブクラスを定義

バリデーションメソッド

検証したいモデルの中でカスタムメソッドを定義し、validate(単数形)でメソッドを呼び出す。

以下のコードは、:name属性と:email属性を持つUserモデルをカスタムメソッドにより検証する例。

 

  • カスタムメソッドname_or_email_presentsを定義
  • メソッドでは、:name:emailの両方とも空の場合にエラーを追加
  • モデルでvalidateによってメソッドをコールバックとして追加(validateは単数形)

ActiveModel::Validator

ActiveModel::EachValidator

 

Rails – 掲示板 – 新規投稿ページ

概要

サインインユーザーによる新規記事投稿のページを実装していく。

  • サインインユーザーがメニューアイコンをクリックして新規投稿ページへ
    • 新規投稿ページでは、メッセージを入力、画像ファイルを指定
    • サインインしていないユーザーに対してはアクセス制限
  • ここではresourcesによるRails標準のルーティングを使う
  • コントローラーはPostsController.rb

掲示板の第2段階へ

ルーティング

コントローラーに対応したpostsについてresourcesでルーティングを設定する。

config/routes.rb

resourcesにより設定されたルーティングは以下のとおり。

rails routes

コントローラー

PostControllerコントローラーを生成する。アクションについては、生成後のコントローラーファイルを編集することとして、ここでは枠組みだけを生成。

rails generate controller posts

生成されたコントローラーファイルにアクションを追加。

  • new
    • 他画面から遷移して投稿画面をレンダリング
    • ビューで扱うモデルはPostなので、@postUserのインスタンスをいれておく
  • create
    • 投稿画面からのPOSTにより処理が渡され、投稿記事の新規作成処理を行う

またアクション実行前にauthorizeをコールバック登録し、アクセス制限をかけている。

app/controllers/posts_controller.rb

ビュー

newアクションによりレンダリングされるページのコード。

メッセージ入力用のtext_areaとファイル選択用のfile_field、送信用のボタンを配置する。

views/posts/new.html.erb

スタイル

ビューに対する最低限のスタイルを設定。

app/assests/stylesheets/posts.scss

リンク設定

サインインユーザー用ヘッダーメニューのアイコンから記事投稿ページへのリンクを設定。

app/views/layouts/application.html.erb

 

Rails – 掲示板 – モデルとデータベースの準備

概要

第2段階の仕様のうちプロフィールに続いて記事投稿の機能を実装していく。

まず、記事投稿に必要なモデルとデータベースのテーブルを準備する。

  • Post:投稿記事のモデル
  • PostImage:投稿記事に付加可能な画像ファイルのモデル

手順の詳細は「モデル生成とマイグレーション」、「アソシエーション~基本」を参照

モデルの生成

Postモデル

以下のRailsコマンドでPostモデルを生成する。Userモデルを参照するため、user:referencesを指定。

生成されたモデルの内容を確認。references指定に基づいて、Railsによりbelongs_toが記述されている。

app/models/post.rb

モデルと同時に生成されるマイグレーションファイルを確認。ここでもusersテーブルを参照する外部キーが設定されている。

20210331121751_create_posts

PostImageモデル

以下のRailsコマンドでPostモデルを生成する。Postモデルを参照するため、post:referencesを指定。

生成されたモデルの内容を確認。references指定に基づいて、Railsによりbelongs_toが記述されている。

models/post_image.rb

モデルと同時に生成されるマイグレーションファイルを確認。ここでもpostsテーブルを参照する外部キーが設定されている。

20210331122545_create_post_images.rb

アソシエーションの設定

Userは複数の記事(Post)を投稿するため、Userモデルにhas_manyを追加する。

models/User.rb

 

1つの記事(Post)が複数の画像(PostImage)を持つことができるので、Postモデルにhas_manyを設定する。post_imagesと複数形になっている点に注意。

さらに、記事投稿時に画像ファイルも削除するよう、dependentも設定。

models/post.rb

post_image.rbPostに従属するが、Railsによってbelongs_toが設定済みなので編集不要。

マイグレート

以上の設定に基づいてマイグレーションを実行。その結果、postsテーブルとpost_imagesテーブルが生成される。

postsテーブル、post_imagesテーブルの構造を確認。

rails consoleでの確認

rails consoleでアソシエーションが機能しているか確認。

まず、Userに属するPostデータとPostに属するPostImageデータを作成。

テーブルに登録されたデータを確認。

このあとpost.destroyにより、postデータとPostImageデータが連動して削除される。

 

Rails – アソシエーション – 基本

概要

Railsにおけるデータベースのテーブル間のアソシエーションについて、基本を整理する。

以下のようなテーブルを例にする。Railsが生成するcreated_atupdated_atは省略している。

  • userspostsimagesのレコードはそれぞれUserPostImageモデルのインスタンス
  • PostUserに、ImagePostに属する
  • Userは0以上複数のPostを持つ
  • Postは0以上複数のImageを持つ

アソシエーションの意義

単純にテーブル操作する場合

普通に3つのテーブルだけがある場合に、特定idのユーザーの投稿記事を作成し、その記事が2つの画像を持たせるには以下の様になるだろう。

このときに生成されるデータは以下の様になる。

ここで投稿記事Post(id=1)をそれらに付随する2つの画像データとともに削除する。それには2つのImageを削除してから元のPostを削除する。

このように個別のテーブルを操作する場合、データの生成・登録や削除の際に、

  • 関連するテーブルのデータのidを常に意識し
  • データ間の関連を念頭に置きながら個々のデータを操作する

必要がある。

アソシエーション導入後

テーブル間のアソシエーションを導入した場合、関連付けられたデータの操作が直感的に、またシンプルになる。

データの生成

データの生成は以下のとおりで、親となるデータのidを意識しなくても、具体の親オブジェクトを指定して生成すれば関連付けられたデータが生成される。

上の例では、まずpostscreateした後に、そのインスタンスに従属するようにimagescreateしている。

このようなデータベースへの書き込みを、さらにまとめることができる。

 

最後にsaveするまではデータベースには保存されずidもnilのままだが、オブジェクト間の関係は保たれている。最後に保存するときに、postと2つのImagesのインスタンスが同時に保存される。

データの取得

データの取得は、親モデル.子モデルのコレクションで取得し、親モデルは単数形、子モデルは複数形。

データの削除

そして投稿記事を画像ごと削除する場合には、以下の様にたった1行で済む

さらに、外部キー制約をかけているので、以下のように親のデータだけを削除しようとするとエラーとなる。

アソシエーション設定の流れ

仕様

冒頭の3つのテーブルのうち、PostImageの2つを取り出して考える。以下の様に若干変更。

  • Postcomment要素を持つ
  • ImagePostImageに変更
  • Userとの関係は考えない

2つのモデルの関係は以下のとおりとする。

  • PostImagePostに属する
  • Postは0以上複数のPostImageを持つ
  • Postの削除に伴って、これに属するPostImageのデータも削除される

モデルの生成~外部キー指定

以下のコマンドで2つのモデルを生成する。

PostImagePostに従属するよう、post:referencesを指定している。生成するモデルが属するモデル(親のモデル)をAとするとA:referencesと指定する。

Postモデルについては枠組みのみ生成されている。

app/models/post.rb

PostImageモデルについては、references指定に伴って、Railsによりbelongs_toの1行が追加されている。

app/models/post_image.rb

モデルのアソシエーションの定義

has_many

Postが複数のPostImageを持つことをRailsに伝えるため、Postモデルにhas_manyメソッドを追記する。

dependent

親のデータを削除するときにこのデータも一括して削除するためには、dependent: :destroyを指定。

注意点

  • belongs_to :parentはメソッドの引数が単数形
  • has_many :childrenはメソッドの引数が複数形
  • dependent: :destroyは引数のハッシュで値がシンボル

マイグレーションファイル

Postsモデル

コマンドでの指定に従って、comment要素が設定されている。

PostImageモデル

コマンドで指定したfile_nameのほか、Railsによって以下の外部キーの指定が生成されている。

t.references :user, foreign_key: true

マイグレーション実行~テーブル

マイグレーション実行の結果、postsimagesの3つのテーブルが生成される。

postsテーブル

デフォルトのidcreated_atupdated_atのほか、不通に指定したcomment要素が含まれる。

post_imagesテーブル

デフォルトの要素のほか、Railsコマンドで指定した2つの要素が含まれる。

  • post: referencesの指定に対して、postsテーブルのidを参照する外部キーpost_id
  • 普通に指定したfile_name

アソシエーション設定の確認

rails consoleによる確認

rails consoleでデータベース操作の効果を確認する。

データの生成と保存

2つのPostImageオブジェクトを持つPostオブジェクトを1つ生成し、まとめて保存する。表示は見やすくするために再構成している。

saveより前では3つのオブジェクトともidnilとなっているが、オブジェクト間の関連は保持されている。

postsテーブルとPostImagesテーブルへの登録内容を確認。

データの取得

postsに従属する複数のPostImageデータをループで取り出す例。

この操作はデータベース登録(save)の前でも可能。

deleteに対する制約エラー

PostImageデータを持っている状態でpost.deleteしようとすると外部キー制約エラー

destroyによる一括削除

post.destroyだと従属する2つのImageも削除される

1つの実行文で、当該Postデータとそれに関連付けられたPostImageデータも削除される。

 

Rails – 掲示板 – プロフィール画像アップロード機能

概要

ユーザー設定の枠組みコメント編集機能を実装した。

ファイルアップロードの実装の詳細は「画像アップロード」にまとめており、ここでは以下の仕様のコードと説明のみまとめる。

  • ユーザー設定画面に以下を表示
    • 現在のプロフィール画像
    • ファイル選択要素
    • コメント入力要素(現在のコメント内容を入れておく)
  • 送信時に画像が選択されていれば画像ファイルを保存してファイル名をデータベースに登録
    • 画像保存前に 今の画像ファイルを削除
    • 画像ファイル名はランダム文字列で与える
  • コメント入力は入力されているテキストで更新
  • 更新に成功すればプロフィール画面に遷移
  • 更新に失敗すれば再度ユーザー設定画面に遷移

掲示板の第2段階へ

画像ファイル保存場所

publicディレクトリー下にuser_imagesディレクトリーを作成。ここにプロフィール画像を保存。

users#editアクション

プロフィールコメント編集と同じ。

ルーティング

プロフィールコメント編集と同じ。

edit.html.erbビュー

画像アップロードに関する表示要素は以下のとおり。

  • 現在のプロフィール画像(L6~12)
  • プロフィール画像選択フィールド(L13)

app/views/users/edit.html.erb

イメージファイルをdivで囲んでいる(L6~12)。スタイル設定でdiv要素のサイズに合わせて画像をフィッティング・センタリング

file_fieldのパラメーターキー:upload_fileはモデルのパラメーターには含まれない(L13)。コントローラーでファイルオブジェクトを取り出すためだけに使われる。

ボタンが押されると、update_user_pathupdateコントローラーに制御が移る(L4)。

user_image_urlヘルパー

editビューでプロフィール画像を表示するのにuser_image_urlヘルパーを使っている。このヘルパーはUserに関して使うので、UsersHelperモジュールに書いている。

画像ファイルのパスについては画像ファイルの配置とパス指定を参照

users#updateアクション

次の機能を追加している。

  • フォームからのアップロードファイルの取得
  • ファイルの保存
  • データベースへのファイル名の登録

app/controllers/users_controller.rb

パラメーターからアップロードファイルのオブジェクトを取得(L6)。

user_paramsで得られたパラメーターをnew_user_paramsに保存しているが、ファイルが存在する場合はこれに:image_file_nameがマージが追加される。

ファイルタイプはJPEGかPINGのみで、それ以外はエラーをフラッシュして再度設定画面を表示(L11~20)。

ファイル名の衝突を避けるため、ファイル名をランダム文字列としている(L22)。

現在存在しているファイルを削除する(L27~33)。

ランダム文字列の生成

ランダム文字列の生成は記事投稿にも使うため、application_helper.rbに書く。

app/helpers/application_helper.rb

これを有効にするにはインクルードしておく必要がある。

app/controllers/application_controller.rb

user_paramsヘルパー

プロフィールコメント編集と同じ。

params[:user][:update_file]は直接保存しないため、ストロングパラメーターとする必要がない。

スタイル

プロフィール画像のフィッティングとセンタリング(L20~33)。

L34ではファイル入力要素のスタイルを設定。

app/assets/stylesheets/users.scss

フラッシュの追加

application.html.erbフラッシュの表示を追加(application_signed_out.html.erbと同じ内容)。

  • jQueryの読み込み
  • フラッシュ表示部
  • 一定時間後のスライドアップ

app/views/layouts/application.html.erb

プロフィール画面の変更

プロフィール画像ファイルのアップロードができたので、プロフィール画面にこれを表示させるよう変更する。

  • プロフィール画面が未登録の場合はダミー画像を表示する
  • 画像が存在する場合はuser_image_urlヘルパーで画像のフルパスを取得する

app/views/users/show.html.erb

 

Rails – ファイルのアップロード~ゼロから組み立て

概要

  • Railsで画像ファイルをアップロードする処理を整理する
  • ユーザーのプロフィール画面のアップロードと更新を例にする
  • 更新時、前の画像は削除する
  • 画像ファイル名の衝突をさけるため、ランダム文字列を生成してファイル名にする

フォームからのアップロード情報を受け取る

ビュー

以下のビューが表示されるとファイル選択要素が表示される。

file_fieldに対するキーは:upload_fileと設定しているが、これはモデルに存在しないキーでもよい。

ここでは登録済みユーザーのプロフィール画像を編集する想定で、PATCHメソッドでupdateコントローラーに送信される。

コントローラー

フォームから送られたアップロードファイルに関するデータはparamsに格納されていて、以下で取得できる。

params[:モデル][:file_fieldで設定したキー]

ここではアップロードファイルが指定されているときにupload_fileにアップロードファイルの内容を保存し、その中のoriginal_filenameの値をupload_file_nameに保存している。

UploadedFileクラス

file_fieldからparamsに保存されるのはUploadedFileクラスのインスタンス。

たとえば上のupload_fileの内容は以下の様になっていて、original_filenamecontent_typeがインスタンス変数として参照できる。

また、画像ファイルの実体はreadメソッドで読みだすことができて、これをファイルの保存時に使う(readメソッドは1回しか呼び出せないらしい)。

permitの設定は不要

フォームから得られるUploadedFileオブジェクトをparamsで取得しているが、これに対してrequire.permitに含める必要はない。

Railsのモデルの仕組みによって自動的に入力・保存するものではないため。

ファイルの書き込み

基本手順

  1. アプリケーションの中のファイル保存ディレクトリーを取得
  2. 上記とファイル名を組み合わせたフルパスを取得
  3. 画像ファイルの書き込み

コントローラー

コントローラーのupdateアクションのみ示す。

流れは以下のとおり。

まず事前にプロジェクトディレクトリー下のpublicに必要に応じてサブディレクトリーをつくっておく

/home/.../ex_bbs/public/user_images

Rails.rootはプロジェクトディレクトリーのフルパスを保持したPathオブジェクト

Rails.root.join()でパスにディレクトリーをつなげていく

upload_dir = Rails.root.join("public", "user_images")

upload_dirにファイル名をつなげてファイルのフルパスにする

upload_file_path = upload_dir + upload_file_name

ファイルのフルパスとファイルの実体を指定して、画像ファイルを書き込む。

File.binwrite(upload_file_path, upload_file.read)

データベースへの登録

基本手順

  1. フォームから得られたparamsにヘルパーでパーミッションを適用
  2. その結果にアップロードファイルのファイル名をマージして登録用のパラメーターとする
  3. 登録用パラメーターでデータベースに登録

コントローラー

パラメーターヘルパー

コントローラーで多用されるヘルパーは以下のような形。

フォームから得られたパラメーター(user_paramsの戻り値)は以下のような内容。画像選択以外の要素がないのでパラメーターは空になっている。

パラメーターの調整

フォームで得られた:upload_fileからデータベースに登録するファイル名を取り出し、パラメーターにマージする。

new_user_params = user_params.merge({image_file_name: upload_file_name})

マージ後のnew_user_paramsの内容は以下のとおりで、空だった内容に:image_file_nameが追加されている。

データベースの更新

ユーザーモデルのupdateに調整したパラメーターを与えてデータベースを更新する。

@user.update(new_user_params)

ファイルの削除

データ更新の際に、現在登録されているファイルを削除する場合。

ファイル名の重複防止~ランダム文字列

アップロードファイル名にoriginal_filenameを使うと、ユーザー側で指定したファイル名が衝突する可能性がある。その場合、あとから登録した画像で上書きされてしまう。

そこで、ファイル名にランダム文字列を使って、実質上衝突が起こらないようにする。

同じ機能は投稿記事のコントローラーでも利用し、アプリケーションに共通なので、application_helper.rbに記述する。

app/helpers/application_helper.rb

app/controllers/application_controller.rb

そして、アップロード画像のファイル名をランダム文字列とする。このファイル名はデータベースの更新と画像ファイルの保存に共通して使われる。

こうすることで、複数のユーザーが同じファイル名で画像をアップロードしても、ユーザーごとに異なる名前となるため、ファイル名の衝突がおきない。

まとめ

画像ファイルのアップロードのためのファイル群をまとめておく。ユーザーのプロフィール画像をアップロードするケースを例にする。

editアクション

  • ユーザー操作などでルーティングされ、画像アップロードを含むページを表示する
  • ビューで使うセッション中のユーザーのインスタンスをインスタンス変数に保存する

app/controllers/users_controller.rb

ビュー

  • 画像アップロードを含むページ
  • ボタンを押すとPATCHメソッドでupdateアクションにデータが送られるようルーティングしている

app/views/users/edit.html.erb

updateアクション

フォームからのデータを受け取り、以下の処理を行う。

  • 画像の保存(古い画像の削除)
  • データベースのファイル名の更新

app/controllers/users_controller.rb

ランダム文字列ヘルパー

ファイル名の衝突を防ぐランダム文字列生成のヘルパー。

app/helpers/application_helper.rb

 

Rails – 掲示板 – プロフィールコメント編集

概要

ユーザー設定の枠組みに、プロフィールコメントの編集機能を実装する。

掲示板の第2段階へ

ルーティングの確認

ユーザー設定でルーティングは設定済みだが確認しておく。フォームからのデータはPATCHで送られてくる。

ビューの編集

edit.html.erbにコメント入力欄を追加し、スタイル設定のためのdiv要素を加える。

フォームのボタンが押されると、PATCHメソッドでupdate_user_pathにルーティングされる。その際、セッション中のユーザーのIDがparamsに渡される。

app/views/users/edit.html.erb

また、プロフィール画面でコメント表示するようshow.html.erbを変更する。

app/views/users/show.html.erb

コントローラーの編集

editアクション(再掲)

UsersControllereditでセッションユーザーを取得し、ビューで共用できるようインスタンス変数に格納する(ユーザー設定機能で実装済みだが再掲)。

updateアクション

updateでもセッション中のユーザー取得してインスタンス変数に保存する。

そして、フォームで入力されたパラメーターの内容で@user(セッション中のユーザー)の内容を更新する。

現在のフォームから送られてくるのは:comment(と:id)だけなので、この内容で:idで取得済みのユーザーのコメントが更新される。

  • 更新に成功した場合はプロフィールページへ
  • 更新に失敗した場合は再度ユーザー設定画面へ

user_paramsヘルパーの変更

今の設定では、user_paramsの中で取得が許可されている属性にコメントが含まれていない。

そこでフォームから送られてくるコメントのデータを受信可能とするために、user_params:commentpermitに追加する。

スタイルファイル

ユーザー設定ページのスタイルをusers.scssに追記する。

apps/assets/stylesheets/users.scss

実行結果

ボタンを押して内容がセットされると、プロフィールページに遷移して変更が反映される。

 

Rails – 掲示板 – ユーザー設定の枠組み

概要

プロフィールの編集機能は、ユーザー設定機能として追加する。

プロフィールの画像ファイル名とコメントはユーザー属性として追加した。そこでプロフィール編集に限定しない「ユーザー設定」の機能にこれを含め、今後様々なユーザーの属性設定が可能なようにする。

掲示板の第2段階へ

ユーザー設定の枠組み

editとupdate

ユーザー設定の枠組みにはeditupdateを使う。

編集画面 編集処理
URL /user/:id/edit /user/:id/update
Prefix edit_user update_user
action users#edit users#update
method GET PATCH
画面 edit.html.erb edit.html.erb

ルーティング

枠組みに従ってルーティングを設定。Prefixを使ったユーザーごとのリンクはedit_user_path(:id)のようになる。

updateアクションへのルーティングのメソッドはpatchとしている。Railsによって、form_withで扱うモデルがデータベースに未保存の場合はPOST、保存済みの場合はPATCHが送信されるようにHTMLが生成される。

config/routes.rb

コントローラー

枠組みに従ってusersコントローラーにeditアクションとupdateアクションを準備する。

editアクションでは、ビューで表示させるためセッション中のユーザーのオブジェクトをインスタンス変数に格納する。

app/controllers/users_controller.rb

ビュー

users#editでレンダリングされるビューを準備する。

  • @user.nameを表示させて、受け渡しを確認
  • form_withbuttonを配置して、フォームのボタンが押されたときのメソッドを確認

app/views/users/edit.html.erb

メニューの追加

ヘッダーメニューにユーザー設定の項目を追加する。

app/views/layouts/application.html.erb

動作確認

ここでヘッダーメニューのユーザー設定をクリックすると、以下の画面が表示され、@userが渡されているのがわかる。

ここでボタンを押したときの、Railsサーバーのコンソールの表示は以下のとおり。

PATCHメソッドであることや、URLのパターン、params:idが1にセットされていることがわかる。

留意点

editのルーティングの書き方について

ここではeditへのルーティングを以下の様に書いた。

この場合、たとえばユーザーIDが1の設定ページのブラウザでのURLは以下の様になる。

http://localhost:3000/users/1/edit

一方、このルーティングを単に以下の様に書いても通る。

このときのURLは次のように形が違うが、ページは適正にレンダリングされる。

http://localhost:3000/users/edit.1

どちらのルーティングの書き方でも、Prefixによるヘルパーは、IDに対応して問題なくルーティングしてくれる。

edit_user_path(:id)

edit/updateのアクションについて

前述のように、モデルのインスタンスがデータベースに登録済みであれば、フォーム実行時のメソッドはRailsによってPATCHとされる。

これをPOSTなどに変更したい場合は、以下の様にform_withでメソッドを指定し、ルーティングのメソッドもそれに合わせる。

コントローラーでのIDの指定について

UsersController中、showアクションでユーザープロフィールを表示、editアクションとupdateアクションではプロフィールの変更を行っている。

showアクションでは、データベースからparamsに格納された:idのユーザーを取得している。

一方プロフィールを編集する場合、セッション中のユーザーのID(user_in_session.id)を使っている。

params[:id]を使うと、他のユーザーのプロフィールにも反応してその内容を見られる。

プロフィールページはサインインしているユーザーのみ見られ、かつ他のユーザーのプロフィールを見られることを想定しているのでこの方法をとる。

一方プロフィールを編集する場合は、サインインしている(セッション中の)ユーザーのデータのみ扱う必要があるので、user_in_session.idを使う。