Now that I have demonstrated how to create a thin Contact form in ASP.NET using jQuery and some AJAX it is time to start making it even better. One of the first rules I learned back in my youth was users will enter anything in any field despite what logic should dictate. They will also not follow explicit instructions. Don't believe me? Then put a form on a web site with no filtering what so ever and examine what data you catch, amazing isn't it?
To force, or help users enter valid information in a web form or any application you may design you have to add validation, hints and other visual clues. The ASP.NET Web Forms framework (see how we are expanding our horizons now) has included a pretty good set of validation controls that naturally work with web controls. I am not going to review them today since they have been around for a decade now. Peter Blum has probably the best package of custom ASP.NET validator controls available that go above and well beyond the out of box set available in ASP.NET.
Since the contact form I have built so far leverages jQuery I want to demonstrate how to implement the jQuery Validation Plugin to embed validation and data hints.
When you implement an ASP.NET Validation control you set several properties on the control to drive its behavior. In particular you need to indicate which control is being validated unless it is a custom validator. The jQuery validation plugin leverages a CSS selector like syntax to apply validation rules. Which of course once you understand how jQuery works, leveraging CSS selectors makes sense. Any element in the DOM, which is just about all of them, can have a class selector attribute defined. I think anyone that has done HTML development knows this, what many may not know is you can define multiple CSS selectors in this attribute (Ah Ha!!).
="prettyForm required phone"
This opens up a world of opportunities to us as developers because now we can really leverage this feature to manipulate the elements on the page. Another thing to note is the class does not actually need to be defined in a style sheet definition for it to be valid to use in the markup. Of course it is a good idea to do so, but not a requirement.
In the above example the input field has three style sheet selectors assigned to it: prettyForm, required and Phone. The first selector, Prettyform, is actually used to control the appearance of the input, at least in my example. The other two selectors may or may not have a CSS definition, but instead will be used by the jQuery Validation plugin to perform client-side validation to the data entered by the user. In this example the field is required and must be a valid US Phone Number. The Validation Plugin already has routines in place to verify a value has been entered for the required fields and where indicated meets a criteria for a valid US Phone number.
There are other custom methods defined for other input types, such as e-mail, dates, numbers, etc. There is even an additional methods add-on included with the package. In fact you can even define your own validation routines and add them to the list. This provides for the ultimate flexibility when defining form validation rules.
Implementing the jQuery Validtion plugin is relatively straight forward. In addition to the jQuery script reference you need to reference the validation script file (shown with the additional methods reference):
Next you need to actually register the validation routine for the form in the jQuery Ready function. This is done by calling the validate function from the form object. If you have a jQuery background this is pretty natural, if not then I encourage you to read up on jQuery fundamentals.
I find it is also a good idea to hide any object with the .error CSS selector applied to it just in case they may be unnecessarily displayed when the page is loaded. The Validation plugin automatically adds these DOM elements to display the validation message to the user and they should not be visible when the form is first loaded, but I had a few trial instances early on where they were displayed.
Now opening the form in a browser will look just like our previous exercises, except now I have added a red star next to the required fields. I have also added a few CSS rules to define the look of the text boxes. Simply clicking the Submit button will cause the validation rules to be executed and messages displayed to the user letting them know what they did wrong.
Once these fields have content in them the form will submit, as long as the e-mail field has a value that meets the criteria of a valid e-mail pattern.
Notice I was able to enter anything I wanted in the textbox, but it was not valid and the validator plugin let me know as soon as I started typing. While numbers are valid in an e-mail address, not having an @ (or in some cases a #) sign and a TLD is the standard e-mail format. If I has added characters to match this pattern the validation message would be suppressed.
At this point you may be asking yourself if the jQuery Validation Plugin works with ASP.NET Web Controls? Absolutely!! Again all you need to have are the script references to jQuery and the plugin and you are in business. Then use the CssClass attribute of the Web Control to assign the CSS selector(s) needed for validation of the control. I have included a ASP.NET Web Form version of the contact form using the jQuery validation plugin in the sample code. Here is a snapshot of it in action:
The jQuery Validation plugin provides some very efficient client-side validation. There is much more that can be accomplished with the plugin as it comes out of the box and can be customized to meet just about any client-side validation rule you need to meet. I plan on exploring more options with the validation plugin in the near future. I also want to emphasize that just because you perform client-side validation you should never assume the data your users are providing your application is valid in any way shape or form. You should always perform server-side validation and scrubbing as needed. Client-Side validation should be looked as as a user convenience or user experience feature. You should use it to drive user input and not assume it filters bad stuff from being submitted. After all ' Garbage In = Garbage Out.