Changes between Initial Version and Version 1 of Ticket #9245, comment 15
- Timestamp:
- Jul 7, 2012, 6:40:36 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #9245, comment 15
initial v1 1 Julien, this patch will not work as-is. Your new Field.choices_formfield function is called from Field.formfield using **defaults, but defaults will never include form_class. This means that Field.choices_formfield will always be called with its default value for form_class (None unless overridden by a custom Field subclass) even when the user's intent was to provide a custom form_class for that model field. So for this model:1 Julien, this patch will not work as-is. Your new Field.choices_formfield function is called from Field.formfield using !**defaults, but defaults will never include form_class. This means that Field.choices_formfield will always be called with its default value for form_class (None unless overridden by a custom Field subclass) even when the user's intent was to provide a custom form_class for that model field. So for this model: 2 2 3 3 {{{ … … 8 8 MyCustomFormClass would never make it to bar's Field.choices_formfield, and so an instance of it would not be returned by Field.formfield. 9 9 10 However, it also not work to simply call self.choices_formfield(form_class=form_class, **defaults) from Field.formfield. Subclasses of Field (such as IntegerField) frequently override formfield() and call super's formfield() with a form_class kwarg. This means that calling Field.choices_formfield with Field.formfield's form_class would break models like this:10 However, it also not work to simply call self.choices_formfield(form_class=form_class, !**defaults) from Field.formfield. Subclasses of Field (such as IntegerField) frequently override formfield() and call super's formfield() with a form_class kwarg. This means that calling Field.choices_formfield with Field.formfield's form_class would break models like this: 11 11 12 12