On Fri, Sep 26, 2008 at 9:11 PM, Adam Stein <[EMAIL PROTECTED]> wrote:
>
> While there is are phone number and US state model fields, there doesn't
> seem to be the equivalent zip code field, even though there is a zip
> code form element. Not sure why that would be.
Mostly an accident of history. The US-centric model fields lived in
the core fields package until very recently - moving those two fields
into localflavor was one of the last backwards-incompatible changes
made before v1.0. These model fields have a history that goes back to
the initial release of Django.
The form fields were developed independently as part of the broader
'localflavor' development effort. During that development, form fields
were written for phone numbers, zip codes, states, etc. At some point,
the existing model fields (in core) were linked to the new localflavor
form fields.
Adding a US Zip code model field would be a reasonable contribution to
the localflavor application. If a suitable patch were to materialize
(i.e., a good implementation with docs and tests), it would probably
find itself in core in short order.
> Given that, how do you actually tell the Admin form to use
> us.forms.USZipCodeField for a given model field or somehow associate the
> zip code model field with USZipCodeField? Right now my zip code model
> is a CharField() for lack of a better choice.
That's a reasonable approach. An actual implemention of a
models.USZipCodeField would probably subclass CharField.
As for getting the admin to use your field - you several options:
1) Write a custom modelform, but override the Zip code field. e.g.,
class MyForm(forms.ModelForm):
zip = USZipCodeField()
class Meta:
model = MyModel
This will do all the default form processing for MyModel, but will
override the field used for the 'zip' field. You can then use this
form in your application, or provide it to a ModelAdmin class as the
form that you want the model to use:
class MyModelAdmin(ModelAdmin):
form = MyForm
2) Override the formfield_for_dbfield method on the ModelAdmin class.
When the admin renders a form, it uses the formfield_for_dbfield
method to determine the widget that should be used for model fields of
a particular type. If you want to use your US ZipCodeField
consistently throughout your admin, it may be a good idea to subclass
the base ModelAdmin providing your own default form field.. I haven't
testing this code specifically, but it will end up something like:
class MyModelAdmin(ModelAdmin):
def formfield_for_dbfield(self, db_field, **kwargs):
if isinstance(db_field, models.ZipCode):
kwargs['form_class'] = forms.USZipCodeField
return db_field.formfield(**kwargs)
return super(MyModelAdmin, self).formfield_for_dbfield(db_field, **kwargs)
3) Write your own USZipCode model field that specifies
forms.USZipCodeField by default. This would mean that whenever a model
defines a ZipCode, the admin would get the right form element. This is
the code that you could submit for inclusion to the localflavor
application in Django itself.
Option 3 is the most comprehensive solution, but will also require the
most work (nothing too dramatic, just fiddly, and it's just not
particularly well documented at the moment).
Yours
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
