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.
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.
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.
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.
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.