irregular expressions

[george]

Given that a phone number from my database may be in any form, I have devised the following bit if cunning code to strip it of spaces and hyphens and parentheses:

function parceMyPhone(pValue) {str1 = pValue.replace(/\040/,'');str2 = str1.replace(/\041/,'');str3 = str2.replace(/\032/,'');retVal = str3.replace(/\045/,'');alert(retVal);

where pValue is a phone number. But this is not working. There must be something in my replace method that I have over looked.

[boen_robot]

OK, this I have to ask... WHY do you have different types of phone in your DB? Why don't you format the phone number on the server BEFORE putting it into the DB, and only then simply output it?

[jeffman]

Just use escaped versions of the characters themselves:str.replace(/[\(\)\- ]/g,'');Notice that "space" doesn't need to be escaped.

[george]

OK, this I have to ask... WHY do you have different types of phone in your DB? Why don't you format the phone number on the server BEFORE putting it into the DB, and only then simply output it?

Good Question. I have fixed the data in the database. All the phone numbers I imported from the various excel sheets are in proper (800) 321-4545 format. I also have a java script function that makes sure every phone number is input from the keyboard in this format. But to do this, I had to turn my one phone number field into four input fields, area code, station code, last four and extention. So I when a record is called up for possible edit, I must take the properly formatted number from one column in my table, and parce it into the three or four fields with no non-numeric characters that is displayed. If you know of a better way, please share.

[george]

Just use escaped versions of the characters themselves:str.replace(/[\(\)\- ]/g,'');Notice that "space" doesn't need to be escaped.

Thanks a lot. With that one line of code you just taught me a lot obout regular expressions.

[boen_robot]

Good Question. I have fixed the data in the database. All the phone numbers I imported from the various excel sheets are in proper (800) 321-4545 format. I also have a java script function that makes sure every phone number is input from the keyboard in this format. But to do this, I had to turn my one phone number field into four input fields, area code, station code, last four and extention. So I when a record is called up for possible edit, I must take the properly formatted number from one column in my table, and parce it into the three or four fields with no non-numeric characters that is displayed. If you know of a better way, please share.

Let the user type in the phone number in any format they are comfortable with (but do make sure you say if you want a country code, a network code, etc.). Then turn the + into "00", strip out all other signs in the number, and reformat it the way you want it. Let your server, not JavaScript do this manipulation. If you want to show the user what they have inputted, do so in a confirmation page (which will show all data they've inputted) OR show the number right below the field they're going to be inputting their number.I'm saying to let your server do this, as users can turn off JavaScript, or it may not be available. Server side formatting will ensure you get the right format in all cases.

[george]

I'm saying to let your server do this, as users can turn off JavaScript, or it may not be available. Server side formatting will ensure you get the right format in all cases.

My audence is all USA, working for a particular org, and will need to enable their javascript if it is not. The line has to be drawn, and we draw it according to our audence. I never have understood the reason people use server side form validation. I try and limit traffic between client and server where I can. No big graphics either. Most of our people are using dial up. And this is a scheduling program, not a selling or entertainment page.

[boen_robot]

My audence is all USA, working for a particular org, and will need to enable their javascript if it is not. The line has to be drawn, and we draw it according to our audence. I never have understood the reason people use server side form validation. I try and limit traffic between client and server where I can. No big graphics either. Most of our people are using dial up. And this is a scheduling program, not a selling or entertainment page.

Alrighty then. Do all of the stripping and all on the client, so that in the end your server only receives plain numbers. On the server just ensure the input is an integer (hence you've stripped all signs, all phone numbers would have to be integers), format the number as you want it, and put into the DB. You get the best of all worlds. Users with JS off will either have to enable JS, or input the number with numbers only (and they won't get a preview. Ha! Serves those bastards right!).

[jeffman]

I've run into a lot of sites that come right out and tell you not to punctuate your phone number. I even appreciate not having to enter parentheses. Filling out forms is chore enough.Glad I taught you something, George, but don't think I'm an expert. Regex is a dark, mysterious world designed by Orcs, I think. Worth learning more about, though. As you noticed, just a few characters can do a whole lot of work.

[jesh]

I never have understood the reason people use server side form validation. I try and limit traffic between client and server where I can.

It is because, as boen_robot suggested, javascript can be disabled. Also, someone who knows how to do it can keep javascript enabled and yet bypass just about any validation that you run on the client.It's all well and good to perform client-side validation - I do it on every form I build - it's just not a good idea to rely completely on it. Validate the form client-side, then, when the form is submitted to the server, run it through some validation again. If the data came back correctly because of the client-side validation, then there doesn't need to be a round trip from client to server. If the data didn't come back correctly because of some bored programmer, then you can still verify that your data is in the format you want and send the request back to the client to force valid input.

[george]

Ever fill out a web form, submit it, then 10 seconds later have it reappear with a message about a manditory field not being filled in? You fill it in, submit it, then ten seconds later learn that another manditory field has not been filled in? That kind of checking can be done client side. It is quicker, and less agravating to the user. Another famous after form submit message is "That user name is already taken" Using AJAX, the user name checked when the field is exited, without interferring with the user's flow. Before the rest of the form is completed, the 'used name' message can appear. Besides, for forums and the like, the unique user name requirement is over rated. I once found myself in a room with five Georges. A litteral room. My name is not that uncommon, but this was a once in a lifetime occurance.

[jeffman]

Client side validation is NOT for security. It's for the user's convenience, since no one want to wait 5-30 seconds just to find out they left a required field empty. Real validation must happen on the server.

[george]

It is perhaps good that I do not work for a bank.

[jesh]

That kind of checking can be done client side. It is quicker, and less agravating to the user.

In case you missed this in my earlier post:

It's all well and good to perform client-side validation - I do it on every form I build - it's just not a good idea to rely completely on it.

[boen_robot]

It is perhaps good that I do not work for a bank.

That's not really an excuse. Phone numbers are still personal data. And besides, what if someday you or your boss (or whoever) decides to open up this app into the public for whatever reason? Would you rather fix security holes (and I mean HOLES) then?The point is not whether to use client side OR server side validation. The point is to use client side AND server side validation.The way I've suggested you use above relies on JavaScript formatting the data correctly. The server then only ensures if JavaScript has done the formatting. It won't reformat the data if invalid, it won't try to guess invalid data... it will just accept or reject data based on whether JavaScript has the job done. THAT is the least kind of server work you can do while still being secure.The kind of scenarios you describe can be prevented with client side validaiton. OK. Then do it. No one is telling you not to. Just make sure the server also ensures this required field was filled.