> > Thanks, the accompanying discussion is very interesting and on point.
> > But as someone there points out, why stop at widgets?
>
> Because customizing widgets is a common request, unlike other attributes.
But customizing fields is quite common, no? I agree that it's rare
that you will want
> Please file a ticket for the documentation fix it would be greatly
> appreciated. :-)
Will do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
In terms of backward compatibility, perhaps there could be a new
keyword argument to Field, something like with_model_defaults, that
the user would use to indicate a desire to get the attributes from the
Model. How would this work? Maybe something like this (this is just a
sketch):
> Well, surprise is in the eye of the participant. As noted above, it
> would be surprising to a lot of us if it did pick up the attributes
> because it removes control from the user. The current behaviour isn't
> illogical.
Oh, I wasn't suggesting that the user shouldn't be able to override
On Wed, 2009-08-12 at 20:05 -0700, Kevin Henry wrote:
[...]
> But if you decide to customize the widget, for example:
>
> class AuthorForm(forms.ModelForm):
> name = forms.CharField(widget=forms.TextInput(attrs={'size':80}))
>
> class Meta:
> model = Author
>
> the form field
Take a simple Model and ModelForm like this:
class Author(models.Model):
name = models.CharField(max_length=80, blank=True, default="Joe",
help_text="A name")
class AuthorForm(forms.ModelForm):
class Meta:
model = Author
The resulting form will reflect the desired help text,
