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

Reply via email to