RE: [Best Practices] phone numbers?

Sounds like a chance for an expert to create a phone number class
(plugin, etc.) that we can all use…maybe with a simple parameter like
country to drive the output formatting.

Thanks for all the replies. My conclusions are these:

  1. Users make mistakes, and don’t always format the entries the same
    way.
    ie. (253)111-2222 vs 253/111-2222 vs 253-111-2222 or ever (253)
    111-2222
    x48996 { for US phone nbrs}. The inconsistancy bothers me.

  2. Pragmatically speaking. It is worth the effort control to validate
    the
    phone numbers? In this case, not really. Humans will be able to read
    them. That’s what matters most. Agile Programming methodology says
    don’t
    implement more than you need to, (or something like that).

  3. A plugin would be nice. Something to look into when I have time.
    Unless someone beats me to it :slight_smile:
    -Larry

Customers really like putting in numbers THEIR way.

So, store what they enter for view and editing, as
well as a normalized version to operate on internally.

On Wed, Jul 12, 2006, Larry K. wrote:

Thanks for all the replies. My conclusions are these:

  1. Users make mistakes, and don’t always format the entries the same way.
    ie. (253)111-2222 vs 253/111-2222 vs 253-111-2222 or ever (253) 111-2222
    x48996 { for US phone nbrs}. The inconsistancy bothers me.

Yeah, you have to get over that. Just let them enter whatever they
like, run your validation, and store it as-entered. Or do crazy
munging, it’s up to you :slight_smile:

  1. Pragmatically speaking. It is worth the effort control to validate the
    phone numbers? In this case, not really. Humans will be able to read
    them. That’s what matters most. Agile Programming methodology says don’t
    implement more than you need to, (or something like that).

It’s easy to validate US number. Strip out everything that’s not a
digit, strip off leading 0s and 1s, and make sure the result is at least
10 digits long. I’d say writing those two regular expressions is worth
it :wink:

Ben

(joining this conversation late)

I have found the following to effective:

  1. allow users to enter data the way they want (support multiple
    methods)
  2. validate all formats you support (add them as users require)
  3. normalize the data before insert (update)
  4. on retrieve, standardize the data (good place for
    internationalization)

All work is done in the model.

(this code was previously posted, and criticized for being not
factored enough. feel free to implement the concept as you feel it
requires. grin)

Hopefully you can use this pattern - Works well for postalcodes
(zips), dates, and other key High Value data.

class Contact < ActiveRecord::Base

protected
#validate the phone formats accepted
def validate
if errors.on(“phone”).nil?
validate_phone = self.phone_before_type_cast.gsub(/[^0-9]/,"")
if !validate_phone.nil? and validate_phone.length != 7 and
validate_phone.length != 10
errors.add(“phone”, “number is not correct. Either a 7 or
10 digit phone # must be specified.”)
end
end
end

#format the phone number for display
def after_find
self.phone = “#{self.phone_before_type_cast[0…2]}-#
{self.phone_before_type_cast[3…6]}” if !self.phone.nil? and
self.phone_before_type_cast.length == 7
self.phone = “(#{self.phone_before_type_cast[0…2]}) #
{self.phone_before_type_cast[3…5]}-#{self.phone_before_type_cast
[6…9]}” if !self.phone.nil? and self.phone_before_type_cast.length
== 10
end

#remove all non-numbers
def before_save
self.phone_before_type_cast.gsub!(/[^0-9]/,"") if !self.phone.nil?
end


end

them. That’s what matters most. Agile Programming methodology says don’t
implement more than you need to, (or something like that).

It’s easy to validate US number. Strip out everything that’s not a
digit, strip off leading 0s and 1s, and make sure the result is at least
10 digits long. I’d say writing those two regular expressions is worth
it :wink:

My old phone number would pass… 352-2554 x204, but you still have no
idea what the area code is… just something to keep in mind…

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs