webアプリ制作での注意事項
[決められた期間でappを完成させるために注意すべきこと]
工程数を減らす
特に工程が増えるのはform画面の制作。 何か機能を実装させていくのあたりform画面が増える場合は作業内容がかなり増加することを考慮する。[例：モデル/urlのネスト関係,viewの制作,バリデーションの回数、テスト内容など]
基本的にformにおいて入力項目は必要最低限にする。[例：ログインではemail.passwordのみなど]
ログイン画面でカラムの状態で判断する
[前提]
- ログイン画面ではemail.passwordを使用している
- member:モデル使用してdeviseでユーザ機能を実装
- member_status:カラム:boolea型:default:false[会員登録状態]:true[退会済]
- falseならログイン:trueならログイン出来ないようにする
[ポイント]
session/newではemail.passwordしか用いてないのでparamsではemail.passwordしか使えない=>emailを用いてレコードを取得してそれがパスワードを一致するか・member_statsuの状態をチェックする
devise superの記述はそのまま使用する
[コード]
def create
# emailを受け取る処理/emailカラムで検索するのでfind_byメソッドを用いる.またemailだとカラム名重複する場合があるので何モデルかも示すように指定する。.doencaseは大文字を小文字に変換するメソッド
@member = Member.find_by(email: params[:member][:email].downcase)
# emailで存在しているか調べる
if @member
＃valid_password?で引数で受け取った値が@memberでも有効か検証し、同時に@memberのmember_statusがture[退会済み]か確認する
if (@member.valid_password?(params[:member][:password]) && (@member.member_status == true))
#もし両方の条件がtrueだった場合
flash[:error] = "退会済みです。"
redirect_to new_member_session_path
else
# もしtrueでなかった場合
super
end
#emailで検索した際にレコード自体を持って来れなかった場合
else
flash[:error] = "必須項目を入力してください。"
redirect_to new_member_session_path
end
end
[大事]
- 先にどのような条件で分岐させたいか洗い出す - emailでまずレコードを取得する
ログイン・ログアウト後のリダイレクト先を指定する[devise]
[前提]
- deviseを使用しユーザー機能を実装している
- Admin / Memberモデルを使用している
- 今回はそれぞれのログイン・ログアウト後のリダイレクト先を指定する
- またそれぞれのモデルのurlやコントローラをわかりやすい形にするため階層構造にしている [get "admins/secction/new" => "admins/admins#new"]
[注意]
今まで一つのモデルを用いていたが、複数モデルを扱う際リダイレクト先を指定したくなった。
[今までの方法]
private
def after_sign_in_path_for(resoure)
root_path
end
[考え方] in_application.controllerに記載する。処理の条件を記載する。
private
def after_sign_in_path_for(resource_or_scope)
if resource_or_scope.is_a?(Admin)
admins_orders_top_path
else
root_path
end
end
def
after_sign_out_path_for(resource_or_scope)
if resource_or_scope == :member
root_path
elsif resource_or_scope == :admin
new_admin_session_path
else
root_path
end
end
ER図作成時の注意点
[テーブルの整理(各テーブルのレコードの整理)・別テーブルやカラムに対しての考え方]
「繰り返し項目を削除する」そのカラムがアクターのアクションによって増えるか
[特に、毎回増加するか（会員のテーブルは増加するが頻度は高くない。投稿については利用者の悪所によって毎度作成される）]、増加する場合は別テーブルにしてそちらを子テーブル、切り離した元のテーブルを親テーブルと考える。
「外部キーで置き換える」関連づけた場合どちらかに影響してもシステムの使用上問題がないか考慮する。
[注文テーブルなどは注文した後に関連づけたテーブルでの値の変化を受け付けたくないので、カラムを別テーブルに分けず自分のテーブルにカラムを作成する] [ユーザーテーブルなどは会員情報・名前などの変更が後から存在する可能性があるので別テーブルに行う]
登録した情報を修正するか
頻度は高くないが増えるか[会員登録などで]
- 同姓同名を区別したいか
「マスタ項目を分割する」
そのカラムの情報はある程度決まったパターンのみか
そのパターンをあとで追加・修正する可能性があるか
パターンがレコードごとにわかりやすい形で表したいか
[商品のジャンルは、ある程度決まっており追加修正の可能性がある]
[注意]
関連づけたテーブルから値を持ってくる場合
どっちかが消えると消える
どっちかのdateが変更すると引っ張ってくるほうも変化する
その２点でテーブルやカラムをチェックしてそれで良いか確かめる
新規登録する際に
別テーブルからdateを引っ張ってくる
＝＞
① どっちかが消えると消える
② どっちかのdateが変更すると引っ張ってくるほうも変化する
＝＞
注文「table dbに保存する」→ きっちり形を残す 紙に描いて残すイメージ
viewなどでそのテーブルでカラムを記載する
