Opened 12 months ago

Closed 12 months ago

Last modified 11 months ago

#35035 closed Cleanup/optimization (wontfix)

BaseFormSet should use Form's default_renderer before defaulting to get_default_renderer().

Reported by: Christophe Henry Owned by: nobody
Component: Forms Version: 4.2
Severity: Normal Keywords:
Cc: David Smith Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When creating a BaseFormSet using a subclass Form that defines default_renderer to a custom, it's a bit disturbing that the BaseFormSet does not try to use this renderer before defaulting to get_default_renderer(). This requires the user to always explicitely specify the renderer when subclassing BaseFormSet or using formset_factory, which is error prone.

I propose the following: when instanciating a BaseFormSet, if self.renderer is None, instanciate an empty form with self.empty_form (the form's default_renderer may be a property) to get the form's default_renderer. If this one is None, default to get_default_renderer().

Change History (3)

comment:1 by Mariusz Felisiak, 12 months ago

Cc: David Smith added
Component: UncategorizedForms
Resolution: wontfix
Status: newclosed
Summary: BaseFormSet should try to use provided Form's default_renderer before defaulting to get_default_renderer()BaseFormSet should use Form's default_renderer before defaulting to get_default_renderer().
Type: BugCleanup/optimization

Thanks for the report, however, this was discussed and rejected when we were working on #34532, check out comment.

comment:2 by Christophe Henry, 11 months ago

Ok. Thank you for the information. I now realize that I tried to fix something that was already fixed in Django 5.0. Would it be possible to backport this fix to Django 4.2? Do I need to open a new ticket for this?

Version 0, edited 11 months ago by Christophe Henry (next)

in reply to:  2 comment:3 by Mariusz Felisiak, 11 months ago

Replying to Christophe Henry:

[]Ok. Thank you for the information. I now realize that I tried to fix something that was already fixed in Django 5.0. Would it be possible to backport this fix (95e4d6b) to Django 4.2? Do I need to open a new ticket for this?[]

Django 4.2 is in extended support and it no longer receives bugfixes (except security patches).

Last edited 11 months ago by Mariusz Felisiak (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top