業務アプリの入力欄は、妥当性のチェックが不可欠です。
そのとき、警告の通知方法をどうするかは、設計者の意識で変わります。
Webアプリだと、PostBackを伴うのは避けたほうが良いので、 Submit時に行うことを推奨してます。
クラサバアプリだと、LostFocus時にCheckしたり、TextChange時にチェックしたりするのが多いようです。
項目単位のチェックだけでは完璧にはなりません。複数の項目で統合的にチェックする必要があるからです。
たとえば、年、月、日の欄が３つのTextBoxで実装していたり、受注日 < 納品日 などの条件チェックがあるからです。
画面単位のチェックは不可避です。ことのとき、複数項目にエラーがあるときの通知方法を、えらへ項目を赤反転させた上でDialogで表示させて、OK釦を押させるか、通知欄に文言をラベルで表示するか。
何が効果的かは、顧客の過去の経験則にもよるので、サーベイしてから、決めるのが良いようです。
TextChange時にチェックして、都度、MessageBoxをだすのは、頻発すると、都度OKを押すのが鬱陶しくなったりします。
また、複数箇所にエラーが有っても、1件目のエラー内容だけを表示する、システムもあります。
私は、これは手抜き感を抱きます。n件までのエラーは、反転した上で、列挙するのが良いと思います。
クラサバでTextChangeやLostFocus時の項目単位のチェックすることに慣れた人が、Webアプリを担当したとき、この仕組みを踏襲して、PostBack多発の画面を作ってしまう人がいたりします。
「AutoPostBackはトラフィック増加するし、画面がちらつくから止めた方がよい」と指摘すると、「各項目をAJAXで作ったからちらつかなくなった。」.....うーん。違うんだけどなぁ。
IDEで Webもクラサバもお手軽に同様に作れるようになった反面、両者の特性を認識しない開発者が出てくるのは、皮肉なものです。
手順が簡単になると、技術力の平均値が下がるのは、避けられない道です。裾野が広がると、広がった分だけ下がります。
しかし、トップレベルも上がるので、善し悪しでいうと、善いこととされます。(これは以前にも書きました。)
工業製品に限らず、農業も、機械化、農薬化が進んで、「こつこつ手作りの技術が下がった」と言う人もいます。
病院では、測定器具が発達して、医者は人に向かずに機械の数値で処方しているとも聞きます。
洗濯板で洗濯できない人に対して「洗濯技術が欠けている」と言えないでしょう。
竈で始めチョロチョロ中パッパの火力調整して、米を炊けない人に対して「飯が炊けない人」と非難できないでしょう。
四サイクル／２サイクルエンジンの違いを知らなくても、運転は出来ます。「無知な人」と非難できるでしょうか。
こういった現象を「進歩」とみるか「嘆かわしい」とみるかは、難しいです。メンタル的に「退化」とするほうが、迎合的ですが、発展過程には不可欠な現象な気がします。
クラサバと同じ流れをWebに持ち込むと、問題多発なので、学習事項は残るので、上記の事象と同等ではない....と指摘されるかも知れません。しかし、Webアプリが SilverLighteなど他の形態に変われば、類似した作りが可能になるかも知れません。
そう考えると、断定できる事柄って無いのかも知れませんね。