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
http://srikanthjeeva.blogspot.com
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:http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#M002168
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 861069445464France Country code 33
France Local 06 87 71 23 45
France International 33687712345etc. 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.
