Opened 5 years ago

Closed 2 years ago

Last modified 2 years ago

#13972 closed New feature (wontfix)

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

Reported by: mitar Owned by: nobody
Component: Forms Version: 1.2
Severity: Normal Keywords:
Cc: mmitar@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

form_utils.py (728 bytes) - added by mitar 5 years ago.
A function wich allows callables access to the request

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by mitar

A function wich allows callables access to the request

comment:1 Changed 5 years ago by mitar

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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

comment:2 Changed 5 years ago by mk

  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:3 Changed 4 years ago by graham_king

  • Severity set to Normal
  • Type set to New feature

comment:4 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:6 Changed 2 years ago by apollo13

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:7 Changed 2 years ago by 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?

comment:8 Changed 2 years ago by charettes

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.

comment:9 Changed 2 years ago by 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).

Note: See TracTickets for help on using tickets.
Back to Top