In an aspx page, we use two ways to call a form from javascript:
1. document.getElementById("form1"), or
2. document.form1
and they both work.
However, the "form1" means different things in these two lines:
1. document.getElementById("form1") -- the form1 is the id of the form
2. document.form1 -- the form1 is the name of the form
When working on an aspx page, we only put id="form1" in the form tag, but when the page gets processed and sent back to the client, ASP.NET adds a bunch of stuff to the page, including name="form1" in the form tag (it puts a name in every server control in a page). So that is why document.form1 works in an aspx page without a name for the form.
If you works on an html page, you will have to put name="form1" to get the second method to work.
Thursday, July 24, 2008
Monday, July 14, 2008
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:
And this might be how you hook your form up to the javascript:
If we were using the validator controls as well as the javascript, our javascript would be slightly altered:
And instead of hooking the form tag to the javascript, our aspx file would include a CustomValidator that might look like this:
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.
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.
Form Validation - on the client side (part 1)
I just thought I'd put up a little overview on form validation. First here is a list of good articles on the subject.
http://developer.apple.com/internet/webcontent/validation.html
http://www.elated.com/articles/form-validation-with-javascript/
http://www.w3schools.com/js/js_form_validation.asp
OK, so here is my summary: whenever you are working with any form that is transmitted over the internet, you want to do some kind of validation of the input before you do anything with it. The point is not just to make sure that the input is correct - like you want to make sure a zip code has only numbers and no letters in it - but because forms are a gateway for malicious attacks on a web server. Secure forms will validate on the client side, usually using Javascript, and also on the server side, in the programming language of choice - after all not every client will have Javascript enabled.
However, for this post we are focusing on client side validation - so this is the checking that should be done before the form submits to the server. So when you are a validating a form you are doing a couple things:
1. making sure required fields are answered
2. making sure input is in a correct format
1. is self explanatory to me but more on 2:
Making Sure Input Is In a Correct Format
First, keep in mind that this should be done on ALL fields - both required and optional fields. As for what this means: you want to make sure that the input adheres to what you are expecting. Keep in mind that sometimes you can help achieve this by just designing for it. For example if you are collecting a date - don't give them a text field, give them 3 drop downs. They can't type "yesterday" if you don't give them something to type into ;)
More examples:
- SSN
- email
- phone number
- zip code
- valid range (i.e. if the answer should be 100-500, or 0 to 100%)
Let's look at SSN. To validate it, you would want to make sure that there are 9 characters, all of which are numeric. If you give the user one text field to enter SSN into, then you might start by stripping the field of all non-numeric characters, including whitespace. You would then test the length of the resulting string to see that it is 9.
This is the end of part 1. In my next post, I'll talk about doing client side validation within a .NET project that is also using the built in .NET validators.
http://developer.apple.com/internet/webcontent/validation.html
http://www.elated.com/articles/form-validation-with-javascript/
http://www.w3schools.com/js/js_form_validation.asp
OK, so here is my summary: whenever you are working with any form that is transmitted over the internet, you want to do some kind of validation of the input before you do anything with it. The point is not just to make sure that the input is correct - like you want to make sure a zip code has only numbers and no letters in it - but because forms are a gateway for malicious attacks on a web server. Secure forms will validate on the client side, usually using Javascript, and also on the server side, in the programming language of choice - after all not every client will have Javascript enabled.
However, for this post we are focusing on client side validation - so this is the checking that should be done before the form submits to the server. So when you are a validating a form you are doing a couple things:
1. making sure required fields are answered
2. making sure input is in a correct format
1. is self explanatory to me but more on 2:
Making Sure Input Is In a Correct Format
First, keep in mind that this should be done on ALL fields - both required and optional fields. As for what this means: you want to make sure that the input adheres to what you are expecting. Keep in mind that sometimes you can help achieve this by just designing for it. For example if you are collecting a date - don't give them a text field, give them 3 drop downs. They can't type "yesterday" if you don't give them something to type into ;)
More examples:
- SSN
- phone number
- zip code
- valid range (i.e. if the answer should be 100-500, or 0 to 100%)
Let's look at SSN. To validate it, you would want to make sure that there are 9 characters, all of which are numeric. If you give the user one text field to enter SSN into, then you might start by stripping the field of all non-numeric characters, including whitespace. You would then test the length of the resulting string to see that it is 9.
This is the end of part 1. In my next post, I'll talk about doing client side validation within a .NET project that is also using the built in .NET validators.
Wednesday, July 9, 2008
Remove Whitespace
I added this method to the StringManip class in DCToolbox:
protected string RemoveWhiteSpace(string str)
{
if (str.Length > 0)
{
while (str.IndexOf(" ") > 0)
{
str = Regex.Replace(str, " ", "");
}
}
str = str.Trim();
return str;
}
Tuesday, July 8, 2008
Update a table with data from a view
Well this was my first (that I can remember) update query using data from an outside source - in this case, a view. It was actually documented quite clearly in Books Online. Nevertheless, code example, in case it is of use:
Why I had to use aliases for this to work is more than I understand. Explanations? Comments?
UPDATE table SET table.apple = v.apple
FROM table as t
INNER JOIN view as v
ON t.id = v.id
Why I had to use aliases for this to work is more than I understand. Explanations? Comments?
validators in DCToolBox
I copied into DCToolBox a bunch of the validators that Jinghua has written. The idea is that client side validation will be run first but in a client with Javascript disabled, these server side validators will run instead. I modified a few of them, which were for optional fields, to take an optional T/F parameter. Eventually all of the validators should have this, then they can be used for both required or optional fields.
I also added some new ones, including this:
This is for those situations where at least one of several fields must be answered - for example if you have 4 phone number fields, at least one of them must be filled in. Check all of them, returning a bool indicating if they are answered, and then collect those bools into a List<> and send that list to this function.
I have also written a few functions for returning a simple t/f to indicate whether a field has an answer to work with the above function.
Questions? Comments? Let 'er rip! If you need an example of how to use these validators in a project then let us know and one of us can post it.
I also added some new ones, including this:
public static bool AtLeastOne(ListlistOfResults, string msg, CustomValidator validator)
{
bool bOK = false;
foreach (bool i in listOfResults){
if (i == true)
{
bOK = true;
break;
}
}
//check only if no true items - meaning no field was answered
if (!bOK)
{
validator.ErrorMessage += String.Format(msg);
bOK = false;
}
return bOK;
}
This is for those situations where at least one of several fields must be answered - for example if you have 4 phone number fields, at least one of them must be filled in. Check all of them, returning a bool indicating if they are answered, and then collect those bools into a List<> and send that list to this function.
I have also written a few functions for returning a simple t/f to indicate whether a field has an answer to work with the above function.
Questions? Comments? Let 'er rip! If you need an example of how to use these validators in a project then let us know and one of us can post it.
Subscribe to:
Posts (Atom)