Re: PhoneNumberField
On Wed, 2007-06-13 at 09:49 -0400, Waylan Limberg wrote: > On 6/13/07, Tai Lee <[EMAIL PROTECTED]> wrote: > > > > i'd like to see a single generic phone number field, and different > > methods attached to it that format it to the required formats. usa, > > international, including or excluding country code, using spaces or > > dashes, with or without leading zeroes, etc. > > > > This can all be done with a basic CharField in the model and some > custom newforms widgets. Which brings the question, why do we even > need a PhoneNumberField at the db level? Although I suppose it helps > with the admin, form_for_model, etc. As a general rule, if your data is only coming in via forms, the custom widgets do everything you want. However, if you are also taking data from other places, having normalising convertors and integrity validation checks on the model fields themselves are useful too. That being said, I'm personally not a big fan of adding extra model fields to core. It's always a huge debate about why field X is more useful than field Y and which particular features it should have and soon you end up having to read the instruction manual just to use it. Sure, given a free hand to design things without considering backwards-compat and if it was zero work (which are two reasons why this is only hypothetical), I'd pitch all the US-centric fields from models and put more general things in their place in some cases, but it's not harmful to have the existing ones there either. Making Field sub-classing easier is the solution here, so that people can write whatever customisations suit their particular problem domain. Something like an all-singing, all-dancing telephone number field as Tai wants to use is already possible, I suspect, although it's not really documented how to do it. Other types of fields (particularly those backing onto non-standard database fields -- say CIDR fields in PostgreSQL) are not yet possible. That's work in progress, though. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: PhoneNumberField
On 6/13/07, Tai Lee <[EMAIL PROTECTED]> wrote: > > i'd like to see a single generic phone number field, and different > methods attached to it that format it to the required formats. usa, > international, including or excluding country code, using spaces or > dashes, with or without leading zeroes, etc. > This can all be done with a basic CharField in the model and some custom newforms widgets. Which brings the question, why do we even need a PhoneNumberField at the db level? Although I suppose it helps with the admin, form_for_model, etc. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: PhoneNumberField
i'd like to see a single generic phone number field, and different methods attached to it that format it to the required formats. usa, international, including or excluding country code, using spaces or dashes, with or without leading zeroes, etc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: PhoneNumberField
On 6/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > What happens if a phone number begins with 0 (as some international > numbers are given in the U.S.)? Shouldn't it really be a CharField? It > sure as heck isn't an integer. United States phone numbers consist only of a three-digit area code, three-digit exchange and four-digit phone number; within the US, numbers are never given or used in international format, so there is no need for USPhoneNumberField to worry about international calling codes. An InternationalPhoneNumberField would need to take international calling codes into account, though. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: PhoneNumberField
On Wed, 2007-06-13 at 01:10 +, SmileyChris wrote: > http://code.djangoproject.com/ticket/4551 raises the issue that the > docs say that PhoneNumberField is a subclass of CharField when really > it's an IntegerField. > > Now that's an easy fix, but looking at the code a bit deeper it seems > that USPhoneNumberField (the default newforms field) is cleaned to > "XXX-XXX-" (which isn't going to fit back into an integer field > now, is it). > Shouldn't there be a USPhoneNumberWidget handling the formatting, and > the field be cleaning back to an integer? What happens if a phone number begins with 0 (as some international numbers are given in the U.S.)? Shouldn't it really be a CharField? It sure as heck isn't an integer. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
PhoneNumberField
http://code.djangoproject.com/ticket/4551 raises the issue that the docs say that PhoneNumberField is a subclass of CharField when really it's an IntegerField. Now that's an easy fix, but looking at the code a bit deeper it seems that USPhoneNumberField (the default newforms field) is cleaned to "XXX-XXX-" (which isn't going to fit back into an integer field now, is it). Shouldn't there be a USPhoneNumberWidget handling the formatting, and the field be cleaning back to an integer? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
