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:
-
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. -
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). -
A plugin would be nice. Something to look into when I have time.
Unless someone beats me to it
-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:
- 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
- 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
Ben
(joining this conversation late)
I have found the following to effective:
- allow users to enter data the way they want (support multiple
methods) - validate all formats you support (add them as users require)
- normalize the data before insert (update)
- 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
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…