コンポーネントに有効な値を入力するまで、ダイアログでユーザーをトラップしても問題ありませんか？
ユーザーがさまざまなUIコンポーネントを介してカプセル化された構成の値を変更できるようにするモーダルダイアログがあり、コンポーネントごとに検証を実装する手間を省くか、コンポーネントモデルを制限して、無効な値を選択/入力できるようにしたいとします。ダイアログを閉じるように要求されたときに、すべての値の状態を検証します。
少なくとも1つの値が無効な場合、ダイアログを閉じることは当然拒否します。別のダイアログまたは同様のUIウィンドウ/コンポーネントで無効な状態をユーザーに通知し、値が有効になるまで続けます。
ダイアログまたはそのUIコンポーネントがそれぞれ構成インスタンスに直接値を書き込む場合（ダイアログの構成変更の破棄機能を実装する手間を省きたいため）、これはかなりのことのようです-確信が持てればプログラミング/ユーザビリティの基準に違反していません。
一般的な設計目標は 私に考えさせないでください です。インターフェースは、可能な限りスムーズにプロセスをユーザーに案内する必要があります。
これには、論理的な方法でインターフェースをレイアウトすること、誤ったデータ（日付と時刻など）を入力する機会を制限すること、可能な場合は有効な仮定を行うこと（郵便番号/郵便番号から住所データを取得することなど）、データの形式についてあまり肛門的でないことが含まれます簡単に処理できる場合に表示されます（例：姓、名などの小文字、大文字、または大文字と小文字の混在を許可）。
一般的なフォームエラーは、修正が必要なフィールドに関する明確な情報を伴わない場合、ユーザーを苛立たせる可能性があります。
検証ロジックを1か所にのみ存在させることは素晴らしい目標です。それを言い訳としてユーザーにひどい体験を与えるのは良くありません。
「ダイアログを閉じることを拒否する」べきではありません。あなたは提出を受け入れることを拒否するべきです。ユーザーがcancelを押したい場合は、それらを許可します。
検証コードをどこに置いても、ユーザーがフォームに入力するときに使用します。好ましくは、一度に１つのフィールド。
私が期待する基本的に2つの状況があります：
a：変更は即時です。その場合、私が行うすべての変更は有効な変更になります。インターフェースは、無効な入力を補うことができないように開発されます。すべての入力はデフォルトで有効であるため、この場合、ユーザーをトラップする理由はありません。
b：変更または変更のリストは、[OK]または[適用]ボタンなどを押したときにのみ実行されます。その場合、キャンセルボタンまたは戻るボタンがあることを完全に期待しています。なかなか抜け出せないところに閉じ込めないでください。