Hi,
I am using validates_numericality_of :phone_number
for validation of phone number. The phone number must also accept "-".
for Example, "044-42652144"
Can any one please help how to do it,
Thanks, Srikanth J
Hi,
I am using validates_numericality_of :phone_number
for validation of phone number. The phone number must also accept "-".
for Example, "044-42652144"
Can any one please help how to do it,
Thanks, Srikanth J
Hi,
I am using validates_numericality_of :phone_number
for validation of phone number. The phone number must also accept "-".
for Example, "044-42652144"
You can't use validates_numericality_of for that as it is not a number.
Colin
You can always use the validate method
validate :must_be_phone_number
def must_be_phone_number
errros.add_to_base(“Must be a valid phone number”)
end
Of course you wont just add the error, you will write a routine to validate the phone format
Why don't you use 'validates_format_of' instead? You can use a regexp and make sure there are only numbers and dashes. Here is the documentation page:
http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#M002168
pepe wrote:
Why don't you use 'validates_format_of' instead? You can use a regexp and make sure there are only numbers and dashes. Here is the documentation page:
Better yet, don't validate at all. Instead, just accept any input and remove non-numeric characters. This will enable the user to enter the phone number in the format of his choice.
Best,
That would be fine if no validation were needed but one has to assume that there is the need if the OP is using a validation. Just removing non numeric values will not do the trick if only non numeric values or 'garbage' is entered. You could end up with 'anything' in the field, for example a phone number containing '123'.
On the other hand, validating that the value is just a number doesn't solve entering faulty information... I would still validate the format with a regexp to make sure you get what you're expecting.
pepe wrote:
That would be fine if no validation were needed but one has to assume that there is the need if the OP is using a validation.
No. The OP clearly described his use case, and he is making the same mistake that at least 3 posters a month make on this list.
Just removing non numeric values will not do the trick if only non numeric values or 'garbage' is entered. You could end up with 'anything' in the field, for example a phone number containing '123'.
You could end up with that if you use validates_numericality_of too. My solution is no worse, and I believe it's actually better. I can't even count the number of times websites have rejected my phone number because they didn't like my formatting, when the application should have been smart enough to take all the digits and format them itself.
Best,
pepe wrote:
On the other hand, validating that the value is just a number doesn't solve entering faulty information... I would still validate the format with a regexp to make sure you get what you're expecting.
But you should expect almost anything useful. Don't make the user know how phone numbers should be formatted. That's the job of the application.
Best,
Marnen is correct here and it is actually the easiest way of doing things. Let's say you have someone that placed anything in the field like so:
my number is (492)-4321234 my number is [492]-432-1234 my number is (4924321234)
What is your application is used by other people worldwide?
In this case the country has a country code, a local number, and an international format:
China Country code 86 China Local (10) 69445464 China International 861069445464
France Country code 33 France Local 06 87 71 23 45 France International 33687712345
etc. etc.
As you can see by this example, now you are dealing with formatting of numbers that could have 2 or 3 extra digits. This is exactly why validation fails in some cases because some of the cases are unique enough that it would take a complicated effort to product a simple one.
In this case above you can use regexp to remove all non-digit formats and you could even take it a step farther if you wanted to by reading non-us numbers in their international format based upon their country code. It's up to you.
Alpha Blue wrote:
Marnen is correct here and it is actually the easiest way of doing things. Let's say you have someone that placed anything in the field like so:
my number is (492)-4321234 my number is [492]-432-1234 my number is (4924321234)
What is your application is used by other people worldwide?
In this case the country has a country code, a local number, and an international format:
China Country code 86 China Local (10) 69445464 China International 861069445464
France Country code 33 France Local 06 87 71 23 45 France International 33687712345
etc. etc.
In this case, it probably makes sense to have a separate field for country code, and possibly one for area code.
(And the proper way to write a phone number with a country code is to put a + before the country code.)
Best,
In this case, it probably makes sense to have a separate field for country code, and possibly one for area code.
(And the proper way to write a phone number with a country code is to put a + before the country code.)
Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org
I was about to follow-up with just that.
Have two fields for phone numbers:
US --> Area Code --> Local Number (use regexp to parse out all non-digit chars) International --> Country Code --> Local Number (same regexp as per above)
Now you have a very simple regexp that is removing all non-digit chars and producing number formats for those fields. Based on the user input, you can now format the way the number appears on the page using what Marnen suggested with the + chars.
The nice thing is you've just handled the way phone numbers should work
- they house numbers only. If your visitor can't input their numbers
into the correct fields, that's not your problem but theirs. You've
already worked at making sure you've handled user related input errors
with your application. You cannot handle whether or not a user is smart
enough to type in the right box.
I didn't mean exactly two fields. I just meant fields. There could be 3 fields for us based numbers and 2 fields for international based numbers etc.
Bah time for me to drink another cup of coffee. I meant two fields for
both us and international, not 3 for US.