Field initial value callable should take a request object as an argument

[Mitar]

Currently it is possible to define initial value for a field as a callable. But this is quite limited in use as it does not take any context in which it should run.

I am proposing that it should take a request object. In this way it is possible to set initial values based on a request. For example, based on GeoIP information. We should pass a request object to the form constructor which would then pass it along to the those callables.

I am attaching a short helper function which allows me that I define such callables already. It postprocesses the form class so that request is available to callables. So in the view it is necessary just to construct your form with:

form = initial_accepts_request(request, MyForm)()

It still allows initial values to be passed at construction time and they override callables.

But it would be much better if this would be officially supported.

[Mitar]

A function wich allows callables access to the request

[Mitar]

An example how this can be useful can be found in #5446.

[Matthias Kestenholz]

The form classes do not know anything about requests currently, and the prevailing opinion is that this should not be changed in the future.

The last time that coupling requests and forms came up was during the last refactoring of CSRF protection. It was rejected.

This ticket is probably a candidate for "wontfix", this is to be decided by the core developers though.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Florian Apolloner]

Jupp, wontfix, forms shouldn't have to know about the request.

[Mitar]

But how can you then enable forms to have default values based on the user? For example, that default language is set based on his or her IP?

[Simon Charette]

You should have this initial_data_for_user logic in your views and pass it along to your form when creating it.

See the ​getting help section if you need some support.

[Mitar]

I know that I can do this in the view. But I find this not a nice separation programming logic. Then I have to repeat again and again this in all the views, where it could just be a nature of the view. Yes, I could create a mixin for class-based views to handle this, but it is still complicating things. request should really be available everywhere. Like there is a way (processors) to get it into the templates, there should be a way to get it into forms.

Maybe better way would be that default values functions could be methods of form? So then you would access to self where you could store anything you want (or pass request in the constructor).