#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 <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018b7fe3b2d7-083668ef-9dce-4bad-a7d5-5b9e89d038b5-000000%40eu-central-1.amazonses.com.
