On Tue, 2009-01-06 at 10:45 +1100, Malcolm Tredinnick wrote: > On Mon, 2009-01-05 at 14:33 -0800, DragonSlayre wrote: > > http://docs.djangoproject.com/en/dev/topics/forms/modelforms/ > > > > This lists PhoneNumberField as being a field type, but in the models > > documentation, > > http://docs.djangoproject.com/en/dev/ref/models/fields/#ref-models-fields > > there is no such field. > > > > Does anybody know if this field exists? I'd quite like to use it. > > There's no phone number field for models. Just use a character field.
Sorry, I hit "send" before finishing my post. There's much more to it than this: The model field PhoneNumberField is an historical holdover from the days when Django supported the entire world as known to people in Kansas -- the USA (yes, I'm joking. They also knew Canada existed because they liked music and ... hey... Celine Dion and Bryan Adams! :-)). Since it's release, it's become clear that there are countries outside the US and they also have discovered this telephone-like device and have their own numbering system. So whilst PhoneNumberField did exist at one point, it was more trouble than it was worth, as it only supported North American style phone numbers. Thus, it has been moved to django.contrib.localflavor.us. Long-term, we don't really need a special phone number field, since it is just a text field. Probably with some validation rules, but since we don't have model-level validation in Django 1.0, that's a moot point. Adding an appropriate phone number validator to a text field will be easy in Django 1.1 (or whenever model-level validation lands). At the *form* level, however, we have 473 different phone number fields, it seems. Many of the django.contrib.localflavor.* packages contain some kind of phone number validation and one day, in the distant future, making things less messy there is something I'm going to take a week to do. The reason for the extra form-level fields is that forms do validation and data normalisation, which models don't do (at the moment, at least). Thus there are lots of formats handled for the data input. By the time it gets to the model to be stored in the database, things are much more uniform: a string of digits and, possibly, letters. Hopefully that explains some of the background and helps understand what's going on a bit beyond the documentation. You've kind of identified that we do need to fix that table a little bit, however. Removing things that don't exist any longer. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
