Thanks for the information. I eventually stumbled across a web page
that mentioned formfield_for_dbfield(). I wound up doing this:
class AddressAdmin(admin.ModelAdmin):
def formfield_for_dbfield(self, db_field, **kwargs):
if db_field.name == "Zipcode":
return USZipCodeField(**kwargs)
else:
return
super(AddressAdmin,self).formfield_for_dbfield(db_field, **kwargs)
where my field name is "Zipcode". Since this was the only zipcode
field, this seemed like the easiest solution.
On Sat, 2008-09-27 at 19:42 +0800, Russell Keith-Magee wrote:
> 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 %-)
>
> --
Adam Stein @ Xerox Corporation Email: [EMAIL PROTECTED]
Disclaimer: Any/All views expressed
here have been proven to be my own. [http://www.csh.rit.edu/~adam/]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
