[Django] #34937: Provide a get_form_kwargs for the ModelAdmin

6 views
Skip to first unread message

Django

unread,
Oct 30, 2023, 5:21:21 AM10/30/23
to django-...@googlegroups.com
#34937: Provide a get_form_kwargs for the ModelAdmin
-------------------------------------+-------------------------------------
Reporter: Willem | Owner: nobody
Van Onsem |
Type: New | Status: new
feature |
Component: | Version: 4.2
contrib.admin | Keywords: admin, form,
Severity: Normal | form_kwargs
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
The Django `ModelAdmin` does not seem to provide a `get_form_kwargs`, it
however has a `get_formset_kwargs`. The `get_form` also does not seem to
create a form instance, but return a form class: the result of logic that
works with the `formset_factory`.

In understand that renaming `get_form` to `get_formclass` will likely
break ''a lot'', so that is not an option, but we can define a
`get_form_kwargs` which does not exists up till now, and then use this to
generate optionally extra kwargs that are then injected when we *use* the
form, so something like:

```
ModelForm = self.get_form(
request, obj, change=not add, fields=flatten_fieldsets(fieldsets)
)

# ...

form = ModelForm(request.POST, request.FILES, instance=obj,
**self.get_form_kwargs(request))
```

in the `_chageform_view` for example. This makes it easy to inject for
example the logged in user into the form, which is often done to limit the
form fields.

An alternative for that scenario could be to override
`formfield_for_dbfield`, etc. but the problem with these functions is that
the scope is limited to a single form field, so it does not really is
flexible to do something at the level of the form.

--
Ticket URL: <https://code.djangoproject.com/ticket/34937>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 30, 2023, 5:21:55 AM10/30/23
to django-...@googlegroups.com
#34937: Provide a get_form_kwargs for the ModelAdmin
-------------------------------------+-------------------------------------
Reporter: Willem Van Onsem | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 4.2
Severity: Normal | Resolution:
Keywords: admin, form, | Triage Stage:
form_kwargs | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Willem Van Onsem:

Old description:

> The Django `ModelAdmin` does not seem to provide a `get_form_kwargs`, it
> however has a `get_formset_kwargs`. The `get_form` also does not seem to
> create a form instance, but return a form class: the result of logic that
> works with the `formset_factory`.
>
> In understand that renaming `get_form` to `get_formclass` will likely
> break ''a lot'', so that is not an option, but we can define a
> `get_form_kwargs` which does not exists up till now, and then use this to
> generate optionally extra kwargs that are then injected when we *use* the
> form, so something like:
>
> ```
> ModelForm = self.get_form(
> request, obj, change=not add, fields=flatten_fieldsets(fieldsets)
> )
>
> # ...
>
> form = ModelForm(request.POST, request.FILES, instance=obj,
> **self.get_form_kwargs(request))
> ```
>
> in the `_chageform_view` for example. This makes it easy to inject for
> example the logged in user into the form, which is often done to limit
> the form fields.
>
> An alternative for that scenario could be to override
> `formfield_for_dbfield`, etc. but the problem with these functions is
> that the scope is limited to a single form field, so it does not really
> is flexible to do something at the level of the form.

New description:

The Django `ModelAdmin` does not seem to provide a `get_form_kwargs`, it
however has a `get_formset_kwargs`. The `get_form` also does not seem to
create a form instance, but return a form class: the result of logic that
works with the `formset_factory`.

In understand that renaming `get_form` to `get_formclass` will likely
break ''a lot'', so that is not an option, but we can define a
`get_form_kwargs` which does not exists up till now, and then use this to
generate optionally extra kwargs that are then injected when we *use* the
form, so something like:

{{{
ModelForm = self.get_form(
request, obj, change=not add, fields=flatten_fieldsets(fieldsets)
)

# ...

form = ModelForm(request.POST, request.FILES, instance=obj,
**self.get_form_kwargs(request))
}}}

in the `_chageform_view` for example. This makes it easy to inject for
example the logged in user into the form, which is often done to limit the
form fields.

An alternative for that scenario could be to override
`formfield_for_dbfield`, etc. but the problem with these functions is that
the scope is limited to a single form field, so it does not really is
flexible to do something at the level of the form.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/34937#comment:1>

Django

unread,
Oct 30, 2023, 7:46:11 AM10/30/23
to django-...@googlegroups.com
#34937: Provide a get_form_kwargs for the ModelAdmin
-------------------------------------+-------------------------------------
Reporter: Willem Van Onsem | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 4.2
Severity: Normal | Resolution: duplicate

Keywords: admin, form, | Triage Stage:
form_kwargs | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

* status: new => closed
* resolution: => duplicate


Comment:

Duplicate of #27231.

--
Ticket URL: <https://code.djangoproject.com/ticket/34937#comment:2>

Reply all
Reply to author
Forward
0 new messages