I think formfield_overrides was a wrong decision, but we have it already.
And in Documentation is not deprecated to use "form_class", that's why we
should to describe about "possible errors after field_class overriding" in
documentation.
--
Ticket URL: <https://code.djangoproject.com/ticket/33574>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: SaNjU Saini (added)
* owner: nobody => SaNjU Saini
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33574#comment:1>
* status: assigned => closed
* resolution: => wontfix
Comment:
Interesting example, but out of scope for `formfield_overrides`, which is
just ''a quick-and-dirty way to override **some** of the Field options for
use in the admin'' (emphasis added).
If you **really** want to use CharField here, provide a Form subclass via
`ModelAdmin.get_form()`. (Adding logic to exclude `kwargs` via
`formfield_overrides` is not going to be worth the complexity.)
--
Ticket URL: <https://code.djangoproject.com/ticket/33574#comment:2>
Comment (by Maxim Danilov):
I think, it simply can be added in documentation in box "warning", we
already have this box.
I know Django a little bit, of course, i can change my field in many
places: in form class, in get_form method, in formfield_for_db.
Simplest way is to use "formfield_overrides", this is an attribute. But,
it is not well documented.
That's why i have started this issue and i think we should to describe
about "possible errors after field_class overriding" in documentation.
--
Ticket URL: <https://code.djangoproject.com/ticket/33574#comment:3>
Comment (by Carlton Gibson):
If you'd like to propose a documentation patch, then please do.
My concern would be that that it would be difficult to explain clearly,
such that it's not of benefit to add for most readers, however very happy
to consider!
--
Ticket URL: <https://code.djangoproject.com/ticket/33574#comment:4>