Best practices for client-side validation

从Abobe的flex文档摘要出来：
1) 防患于未然，而不是事后责备。即在用户的输入没有通过检查前，不让用户提交。
2) 即时的反馈。用户输入后，立刻告诉用户成功还是需要修改。
3) 不要影响用户的连贯性。
4) 只有当用户交互以后才能给错误提示，就是说如果一个控件在用户啥都没做之前就给出一堆错误提示是很让人抓矿的。

以下是转载原文。

Best practices for client-side validation

Flex provides you with several methods for validating data. This Quick Start describes a method of validating data that provides the most usable experience for your users.

A usable validation method must adhere, as a minimum, to the following user interface design principles for rich Internet applications.

1. Prevent, Don't Scold

The user should not be allowed to submit a form that has validation errors. The Prevent, Don't Scold principle states that whenever you can accurately prevent users from making an error you should do so, rather than allowing them to make the error and scolding them about it afterward.

A blatant violation of this principle when doing client-side validation is to validate the user's input after the user has submitted a form. In a Flex application, you can create this behavior by triggering validators in response to the click event of your form's submit button.

2. Give Immediate Feedback

The user should get immediate feedback as they are interacting with a control. Users should receive positive feedback when the value of a control becomes valid, and they should receive negative feedback when its value becomes invalid. Giving the user feedback after they leave a control also violates the Prevent, Don't Scold principle.

When a control does not give the user immediate feedback, the user only finds out about the mistake after moving off the control. To correct the mistake, the user has to return to the control, thereby expending more effort. (This example also violates another, related principle, Respect User Effort.) Even more importantly, when a user is editing the value in a field that has a validation error on it, the user doesn't know whether the changes have made the control's value valid. The user has to move off the control to find out, and then return to it to change it again if it still isn't valid.

The default behavior of Flex validators is to listen for the valueCommit event on components. This results in the behavior described previously, where the user receives validation feedback only after the user leaves a control. To give immediate feedback, you must manually trigger validation in response to the change event instead of the valueCommit event.

The examples in the Creating a simple validator in MXML and Creating a simple validator in ActionScript sections demonstrate the user experience when immediate feedback is not given.

3. Let the User Work

Although giving immediate feedback is a good thing, your application should do so in a manner that doesn't interrupt the user's flow. Subtle hints that do not interrupt the user are usually best; you should use modal dialogs, which completely interrupt the user's flow, only when absolutely necessary.

4. Innocent Until Proven Guilty

The user should be warned about a validation error on a control only if they have had a chance to interact with that control. (In other words, you should not perform validation on controls that are in their initial state and initially display a form full of validation errors.) Similarly, resetting a form should remove all validation errors.