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.
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>
* status: new => closed
* resolution: => duplicate
Comment:
Duplicate of #27231.
--
Ticket URL: <https://code.djangoproject.com/ticket/34937#comment:2>