new validation function: isValidPassword

I added a new function to the toolbox to validate a password field specifically, assuming that the password may have upper/lower case letters, numbers, or any one of a few punctuations (see actual code for reference). I'm posting about this because I added it to the ValidateAlpha class.As I did so I thought that really the Alpha is not the most accurate name as there are functions in there that validate strings beyond just alpha. However it's kind of late to rename it since it's widely called.

Just be aware that these kinds of functions may already exist before troubling yourself writing a new one!

Form validation - part 2: the .NET validators

Since as we move forward, some of the team which does more of the front-end work, will start to delve more into contributing by doing some of the client-side validation, I thought it would be good to give an overview of the .NET validators. The first version of ASP.NET I worked with - 1.1 - had validator controls as part of the .NET framework. I bet they had them in the 1.0 version as well although I don't actually know for sure. Now the way these validators were supposed to work was like other .NET controls such as the datalist, or the repeater; you could just drag the control onto your page and hook it up. When the aspx made the round trip to the server and rendered in a browser, it would actually serve as client side validation of whatever field you hooked the validator control up to. The trouble was the 1.1 validators created javascript which only worked on IE. :P AND if javascript was disabled...no validation at all!

Furthermore, they were somewhat limited in what you could do with them. In the kind of forms we build, we frequently end up with skip patterns. "If you answered No to 12, go to 14" for example, meaning if you answered no to 12, 13 was not required; but if you answered yes to 12, then it WAS required. This was fairly simple javascript to create, but there existed no validator control that could handle it, except for the CustomValidator. And since we already had an extensive library of javascript functions covering most situations that cropped up, it was much simpler to just not use the validators and stick to the javascript.

In 2.0 however, Microsoft vastly improved the way these validator controls worked. Now they:

1. are cross browser compatible. WOW!
2. still work when javascript is disabled
3. have this neat option where you can tell them to ONLY turn on if the javascript is not enabled. COOL!

Our blog user known as tiger figured out how to work out #3 quite elegantly. Therefore #3 is the way we have been going, unless we don't have the hours to cover it. However as our code library goes, it is taking less and less time to even handle this task :)

Now I am going to show you a basic example. Let's say we have a form with one field with id 'greekGod' for "Favorite Greek god" and one field with id 'faveNumber' for "Favorite Number up to 20". Color is a textbox and Number is a dropdown starting with "Choose Number" for the zero index and going to 20.

Normally this might be your validation. Note that the following function actually calls 2 others, expecting them to return true or false individually. The following function is a handy way of checking numerous fields at once, and just returning false (in other words not letting the form submit) if ANY of them are invalid/have a problem:

function checkForm() <-- note it takes no arguments/parameters
{
 if (
  (isNotBlankAlpha(document.getElementById('greekGod'))) && 
  (isSelected(document.getElementById('faveNumber'))
  )
  {
   return true; 
  }
  
 return false; 
}

And this might be how you hook your form up to the javascript:

form onsubmit="return checkForm();"

If we were using the validator controls as well as the javascript, our javascript would be slightly altered:

function checkForm(source, clientside_arguments) <-- note it takes 2 arguments {  
 if (   
  (isNotBlankAlpha(document.getElementById('greekGod'))) && 
  (isSelected(document.getElementById('faveNumber'))   
  )   
  {    
   clientside_arguments.IsValid = true;    
  }     
 clientside_arguments.IsValid = false;  
} 

And instead of hooking the form tag to the javascript, our aspx file would include a CustomValidator that might look like this:

asp:customvalidator id="CustomValidator1" runat="server" errormessage="" clientvalidationfunction="checkForm" onservervalidate="CustomValidator1_ServerValidate" display="Dynamic" setfocusonerror="True"

Note that it is the ClientValidationFunction property of the control that you use to tie it to the javascript. Note that you don't need the parens to call it either. However, notice that the javascript function itself now has 2 arguments. These are a mandatory signature; the source argument refers to the HTML tag that represents the validator control, and the clientside_arguments parameter refers to an object with 2 properties, IsValid and Value. The Value property is the value stored in the input control to be validated. The IsValid property must be set to false or true according to the result of the validation (Programming Microsoft ASP.NET 2.0 by Dino Esposito).

Note that the Value property is not relevant to the way we are using the CustomValidator - we are not using it to validate a single control, which is what the Value would be the value of - but instead we are validating a group of inputs all at the same time. Further, note that the javascript now takes 2 arguments - and it appears that these 2 arguments are in fact passed to the client function by the server, probably passed by the CustomValidator itself. Finally, the client function (javascript function), now that it is being tied to the CustomValidator, needs to set the IsValid property of the args parameters passed into it.

I hope this overview is somewhat helpful in explaining how to tie javascript to the ASP.NET CustomValidator control. Questions, comments, corrections are all welcome.