Thanks for the pointers, that all make sense now. Margie
On Aug 8, 6:47 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sat, 2009-08-08 at 12:09 -0700, Margie wrote: > > [...] > > > Question: If want to use a special widget for a ChoiceField, is it > > true that I need to instantiate the ChoiceField (or TypedChoiceField), > > rather than just setting the .widget attribute on the one that is by > > default created for me (due to it being a modelForm)? > > > I find that if I just do this: > > > self.fields["status"].widget = StatusWidget(task=instance) > > Grep'ing for "choices" in django/forms/*.py would reveal the answer to > this. Have a look at how the Select widget handles choices, since that > is what you're subclassing. > > The "choices" attribute of all the classes in widgets.py is set in the > __init__() method of each widget. In fields.py, have a look at > ChoiceField and you'll see that when you set choices on a field, they > are also set on the associated widget (there's a _set_choices() method > that is part of the "choices" property on ChoiceField). > > What you're doing in your above code is not setting any choices at all. > You need to tell the widget which choices it can use. > > [...] > > > However, I see when debugging that IntegerField.to_python is an > > unbound method: > > > (Pdb) self.coerce > > <unbound method IntegerField.to_python> > > > What is the right thing to set coerce to if I just want it to do > > whatever it would "normally" do for the corresponding model field if I > > wasn't trying to override the widget? In my case I have verified that > > if I set coerce=int that does work, but that doesn't seem very > > general. I'd much rather use whatever the standard coerce method > > would have been if I hadn't overridden the widget. > > I'm not completely convinced this is a great plan, since if you are only > overriding the widget in __init__, then the coerce function will already > have been set up when the TypedChoiceField was created (it's a feature > of the forms.Field subclass, not the widget). If you are overriding the > form field entirely then you know better than Django what the correct > type to use is, so it's actually easier and arguably clearer to just put > in the right thing. > > However, you also have access to the model, so just use the > model._meta.fields[...] entry for the field and use the to_python() > method on that instance. Look at things like > django.db.models.options.Options.get_field_by_name(). > > 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 -~----------~----~----~----~------~----~------~--~---
