Validates_numericality_of , need to accept "-"

Rails
1

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

2

2010/1/25 Srikanth J. [email protected]:

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

3

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

4

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 :wink:

2010/1/25 Colin L. [email protected]

–
Atenciosamente,

Ênio Lopes

5

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:

ActiveRecord::Validations::ClassMethods

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

6

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.

7

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’.

8

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

9

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 Laibow-Koser
http://www.marnen.org
[email protected]

10

Alpha B. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

11

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.

12

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
[email protected]

I was about to follow-up with just that. :slight_smile:

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. :slight_smile:
13

Bah time for me to drink another cup of coffee. I meant two fields for
both us and international, not 3 for US. :slight_smile:

14

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.