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 -~----------~----~----~----~------~----~------~--~---