52438
入力画面と確認画面(入力した内容を確認する画面)があった場合、入力画面で入力した値のエラーチェックは入力画面のファイルでコードを書いてエラーチェックを行うのが適切なのでしょうか。あるいは確認画面のファイルでエラーチェックでしょうか。
CC BY-SA 4.0
2019-01-30T10:44:53.610
52426
2019-01-31T01:41:38.990
17348
question
php
エラーチェック対応のコードを書くファイルについて。
入力項目ごとに個別に行う入力エラーチェックは入力画面で即座に行うのが適切でしょう。

> 入力画面でsubmitボタンを押す  
>  →遷移先の確認画面に「パスワードは大文字、小文字、数字が必須です」と表示される  
>  →「戻る」ボタンで入力画面に戻る  
>  →パスワードのテキストボックスで再入力  
>  →入力画面でsubmitボタンを押す  
>  →遷移先の確認画面に「パスワードは〇文字以上入力してください」と表示される

上記のUXよりも、入力時にテキストチェンジイベントでバリデーションチェックする下記のエラーチェックの方がユーザ体験が優れています。  
※ここではパスワードの仕様と強度の関係性に言及しません。あくまでエラーチェックの例として提示しています。

> 入力画面でパスワードのテキストボックスにフォーカスを合わせる  
>  →「パスワードは大文字、小文字、数字をすべて含めて〇文字以上入力してください」とテキストボックスの右に表示される  
>  →パスワードを〇文字以上入力する  
>  →「パスワードは大文字、小文字、数字をすべて含めてください」とテキストボックスの右に表示される  
>  →条件に合致するようパスワードを入力する  
>  →テキストボックスの右にOKアイコンや「パスワード強度：高」などが表示される

上記の例のように可能な限り入力画面でエラーチェックをすることが望ましいです。  
しかし「既存サービスの会員番号とメールアドレスが一致しない」など、エラーチェックに業務ロジックや外部データとの突合でDB接続やデータ連携が必要な場合があります。  
エラーチェックのバックグラウンド処理で入力画面が遅くなったり不安定になっては本末転倒ですので、その場合は確認画面での実装が必要なこともあります。  
処理速度やサーバ負荷とのトレードオフも勘案して、適切な画面でエラーチェックを行いましょう。

ちなみに複数の入力画面で同一のエラーチェックを行う場合には、そもそもエラーチェックのファイルを分離してバリデーションクラスに独立させるべきかもしれません。  
入力画面と確認画面の双方でバリデーションクラスの必要なエラーチェックを呼び出す実装にすれば、エラーチェックタイミングの仕様変更などにも柔軟に対応可能となります。

参考：  
[【保存版】エラー表示に関するEFOの鉄則15つ](https://f-tra.com/ja/blog/column/6900)  
[エラー処理をパターンにはめよう](https://codezine.jp/article/detail/6553)  
[PHPでバリデーションを共通化してまとめたい](https://teratail.com/questions/116751)
CC BY-SA 4.0
2019-01-31T01:41:38.990
52438
2019-01-31T01:41:38.990
9820
52426
answer