id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
34426	Pass the BoundField instance to the Widget.render	Christophe Henry	nobody	"Django 4's form rendering API is nice, but lacking a important feature to me: the `Widget` used to render a particular `Field` doesn't have any access to the corresponding `BoundField`. This makes rendering the field, label, potential error messages altogether as well as more more complex structures — like fields with subfields, for instance — impossible to render atomically within the widget. If you want to do that, you're forced to go up to the `Form`'s template itself.

My opinion is that [[https://docs.djangoproject.com/en/4.1/ref/forms/widgets/#django.forms.Widget.render|`Widget.render`]] should be passed the corresponding `BoundField` instance.

This would, I think, have 2 benefits:

1. allow easier rendering of complex widgets like [https://github.com/django/django/blob/main/django/forms/widgets.py#L585 ChoiceWidget] using an iteration on the [https://github.com/django/django/blob/main/django/forms/boundfield.py#L59-L60 BoundField] ([https://docs.djangoproject.com/en/4.1/ref/forms/widgets/#radioselect which is what's documented] and would allow unification with [https://github.com/django/django/blob/main/django/forms/widgets.py#L616-L659 ChoiceWidget.options and ChoiceWidget.optgroups])

2. allow rendering together `Form` fields that are related since `BoundField` has access to the parent `Form` (for instance a form with three options: email, phone, and other, respectively related to an email input, a phone input and a text input that are displayed below each).
 
P.S.: This is a feature request but I'm still opening a bug here since I can't join the django-developers mailing-list without a Google account."	New feature	closed	Forms	4.2	Normal	duplicate			Unreviewed	0	0	0	0	0	0