自分が作っている業務アプリは、画面上部にメッセージを表示する専用のエリアがあります。  
入力エラーはここに表示されます。

![画像の説明をここに入力](https://i.stack.imgur.com/wZJ6S.png)

そこで質問です  
1. webシステムではテキストボックスの隣にエラーを表示するのが一般的なのでしょうか  
2. テキストボックスの隣にエラーを表示した場合、ブラウザ上でレイアウトがずれませんか  
3. javaで業務システムを作りたいのですが、入力チェックは何で実装するのがベストですか？  
→ 専用エリアに入力エラーを表示する場合は、  
TABインデックス順にエラーを表示したいなと思いました。
CC BY-SA 3.0
2015-02-16T11:51:57.550
6579
2015-03-04T16:35:24.183
8247
question
java html5
業務アプリの入力チェックについて
一応Webシステム（業務）をメインにしてる経験上。

  1. バリデーションメッセージ表示のパターンで多いのは2つ。

    1. フォームの最上部に入力項目分すべてをまとめて出す
    2. 各入力項目の右、もしくは直下に出す

スマホやタブレットを対象にするなら 2 のパターンにします(スクロール操作は避ける意味で)

  2. リセットCSSを噛ませるのは当たり前ですが、使う端末によって変えるべきです  
用途がタブレットを視野に入れるなら直下の方が無難でしょう。業務上、デスクトップで解像度も指定されているなら横でも下でも見やすい方に出すべきです。  
フォーム最上部にまとめて出すパターンなら li 列挙でしょうから悩まないですね。

  3. 入力チェックは理想「クライアントJavascript ＋ サーバサイド入力チェック」現実解「フレームワークでサポートしているサーバサイド入力チェック」。  
HTML5 なら、その仕様上のバリデーション(<http://liginc.co.jp/web/html-
css/html/42756>)も可能ですが、業務利用だと面倒なことに IE9 縛りがあるかもしれません。その場合、クライアントサイドはまだ
JavaScript を使う必要があります。  
サーバサイドのチェックは、DBに異常値が入らないための設定です。攻撃対策であると考えて下さい。  
重要度は サーバサイド > クライアントサイド です

1, 2 共通で、バリデーションエラー項目は赤着色位する場合が多いです。

3 は、昨今の Java フレームワークなら入力バリデーション位存在しているでしょうから、それを用いるのが一番よいかと懐います。  
ただし、タブインデックスということであれば、クライアントサイドでの実装が必要だと思われます。  
大抵のJavaScriptバリデーションライブラリは、入力アイテムの右か直下に置くので、画面上部にまとめて出す場合は自作したほうが早いかもしれませんね。
CC BY-SA 3.0
2015-02-16T15:02:33.787
6588
2015-02-16T16:25:24.113
2015-02-16T16:25:24.113
380
380
6579
answer
こんにちは。  
入力値の検証結果については、いくつか代表的なパターンがありますが…以下の1つだけを選択する場合や、複合して使う場合もあります。

  1. 画面の固定（主に一番上ないしは一番下など）したメッセージ領域に、1つだけ出す
  2. 項目の横ないしは近辺に出す
  3. エラーのある項目に色をつける（背景色や枠を赤にするなど）

使い分ける理由としては、エラーの見やすさと、ユーザさんがシステムへ入力する手順に依存します。

また、項目の近辺に出す場合は、エラーメッセージを出力してもレイアウトが崩れないような余裕を持たせることが必要ですし、項目ごとにエラーメッセージが表示できないケースも考慮してください。  
例えば、表形式の入力だと、項目の近くにそれぞれ表示するのは難しいですよね。  
ある一定の領域に対してグルーピング化する場合もあります。

また入力値の検証は、クライアント側でもサーバー側でも実装しましょう。  
データベースに保存しない値もチェックする必要ありますからね。
CC BY-SA 3.0
2015-02-19T00:37:59.470
6715
2015-02-19T00:37:59.470
5778
6579
answer
>   1. webシステムではテキストボックスの隣にエラーを表示するのが一般的なのでしょうか
>

エラーメッセージをまとめて表示する場合、一目でエラーが出たことが分かりますが、どの入力項目でエラーになっているかはユーザーがメッセージを見て判断することになります。

入力項目の隣に表示する場合はどの項目でどういうエラーが出ているかは一目瞭然ですが、画面レイアウトによってはエラーが出ていることに気づきがたい場合もあります。(例：スクロールしないとエラーになっている項目が表示されない場合)

どちらが一般的ということはありません。入力項目数と画面レイアウトとユーザーの慣れ次第で決めればよいです。

>   2. テキストボックスの隣にエラーを表示した場合、ブラウザ上でレイアウトがずれませんか
>

レイアウト次第です。ただ一つ言えることは、エラーを表示するとレイアウトが破綻するというのは設計がまずい証拠です。webアプリの場合ユーザー環境によってウィンドウサイズやフォントサイズや画面解像度(サイズでは無くてppiのほう)が違う可能性があることを考慮した設計が必要です。レイアウトが崩れるという心配はそれらを考慮せずにガチガチの画面レイアウトをしようとしているからではないでしょうか。

>   3. javaで業務システムを作りたいのですが、入力チェックは何で実装するのがベストですか？
>

フレームワークを使っているならフレームワークに備わっているバリデーション機構を使うのが第一選択です。そうで無いなら汎用のライブラリか自作するかですが、要件次第なのでベストはありません。小規模なら自作した方が早いかも知れませんし、大規模になったらなったで汎用ライブラリだと融通が利かないという可能性も増えます。クライアントサイドでも同様のことが言えます。

* * *

webアプリの入力値検証について。

webアプリの入力値検証は、サーバサイドでやるのが大原則です。クライアントサイドのバリデーションはブラウザを使わずにリクエストを投げるだけで迂回できます。(余談ですが、同じ理屈で、例えばselect要素を使っていてブラウザでは固定値しか選択できないからといって検証をしないとこれも回避されます。)

サーバサイドの検証は、入力がアプリケーション要件に沿っていることを保証するためのものです。対して、クライアントサイドでの検証はUXの為だと思ってください。全く目的が違いますのでどちらが優先ということはありません。送信ボタンを押してその結果でエラーが分かる、で良いのならクライアントサイドの検証はしなくてもかまいません。

繰り返しになりますが入力値検証は入力がアプリケーション要件に沿っていることを保証するためのものです。セキュリティのためではありません(CSRF避けトークンのようなユーザー入力値以外のデータの検証は例外です)。例えば、アプリケーション要件で定められた文字種にしたがってシングルクオーテーションマークを拒否するのはよいですが、アプリケーション要件にはないのにSQLインジェクション対策と称してシングルクオーテーションマークを拒否したり削除したりしてはいけません。セキュリティの確保はデータを利用するとき(画面表示だったりDB保存だったり)に適切にエスケープするなりSQLであればプレースホルダを使うなりして行ってください。
CC BY-SA 3.0
2015-02-19T13:20:59.957
6785
2015-02-19T13:20:59.957
5793
6579
answer
>   1. webシステムではテキストボックスの隣にエラーを表示するのが一般的なのでしょうか
>   2. テキストボックスの隣にエラーを表示した場合、ブラウザ上でレイアウトがずれませんか
>

B2Cのシステムだと、分かりやすさを優先して、項目の近くに出すことが多かったです。最近は「フキダシ」形式でオーバレイして表示しているのをよく見かけます。この方法だとオーバレイなのでレイアウトがずれる心配が無いですね。  
フキダシのデメリットとしては、沢山のメッセージを一度に表示する場合に見にくくなる事があります。この対策としては、クライアントサイドである程度リアルタイムに(項目からフォーカスが外れる都度とか)検査してメッセージを小出しにするのが良いでしょう。

業務システムの場合は、多少の使いにくさはユーザの習熟でカバーしてもらうことにして、開発コストを下げるために、サーバサイドだけでまとめて検査した結果を専用エリアで通知する、という仕様が多かったです。

>   3. javaで業務システムを作りたいのですが、入力チェックは何で実装するのがベストですか？
>

クライアントサイドでフキダシメッセージを実装するなら、EFOとよばれるジャンルのjsライブラリを使うと楽です。  
サーバサイドは、お使いのフレームワークに付属のものを使うのが良いでしょう。
CC BY-SA 3.0
2015-03-04T16:35:24.183
7453
2015-03-04T16:35:24.183
7572
6579
answer