Validating form behavior
It is possible to create more powerful validation using browser script.This can be hard to justify, however, because script is not always present in client browsers and can be bypassed by malicious users.If you are writing your own validation routines that are potentially time-consuming or that have side effects, it is also important to have an idea of when they will be called. It is important to understand the life cycle of a page.For those used to working with forms in Visual Basic or similar rich client tools, it takes a bit of getting used to.Validation of Web applications is particularly frustrating for other reasons as well.HTML 3.2 is so limited in what you can control and what feedback you get from the user that you can't apply the same tricks you can use on a richer client, such as preventing the user from entering certain characters, or making beep sounds.If this timing is not to your liking and you prefer to evaluate everything in Page_Load, you can do this by explicitly triggering the validation during this event by calling Page. After this has been called you can then check the result of Page. It allows you to check whether the entire form is valid.
Most of our end-users are very diligent, and we want to give them the benefit of the doubt that they will fill in the form correctly before we bombard them with red text.It is a collection of objects of that implement the IValidator interface.I use the term objects rather than controls because the Page cares only about the IValidator interface.On the post-back, validation takes place during step 5, just before the event fires for the button or control that triggered the validation. NET have a property called Causes Validation that defaults to True.
It is the action of clicking on buttons that makes validation happen.
The best place to check the results of validation is in the event handler that triggered the validation.