[Django] #35726: db.models.TextField.formfield() does not behave like CharField.formfield() when null=True

[Django]

#35726: db.models.TextField.formfield() does not behave like CharField.formfield()
when null=True
-----------------------------+-----------------------------------------
Reporter: Ole Laursen | Type: Uncategorized
Status: new | Component: Uncategorized
Version: 5.0 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+-----------------------------------------
I have a specific use case where I need null instead of the empty string
in the database when some text fields passing through a form are not
filled in.

This works fine for CharFields, but I recently discovered that it doesn't
for TextFields. For TextFields they always turn out as the empty string.

It looks like CharField has this specific support for setting empty_value
= None in .formfield(), but TextField does not:

{{{
if self.null and not
connection.features.interprets_empty_strings_as_nulls:
defaults["empty_value"] = None
}}}

I would expect them to behave the same.
--
Ticket URL: <https://code.djangoproject.com/ticket/35726>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35726: db.models.TextField.formfield() does not behave like CharField.formfield()
when null=True
-----------------------------+--------------------------------------

Reporter: Ole Laursen | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: empty_value | Triage Stage: Unreviewed

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------

Changes (by Natalia Bidart):

* component: Uncategorized => Forms
* keywords: => empty_value
* resolution: => wontfix
* status: new => closed
* type: Uncategorized => New feature
* version: 5.0 => dev

Comment:

Hello Ole Laursen, thank you for taking the time to create this ticket. I
understand your proposal and in fact I have created a small project that
reproduces what you describe.

In order to provide a resolution for this ticket, I have made a lot of
research, so I'll share my findings to then explain how I arrived to the
final conclusion.

1. The behavior that you describe is exactly as documented
[https://docs.djangoproject.com/en/5.1/topics/forms/modelforms/#field-
types in this link] (this is a table documenting the mapping between model
fields and their form fields counterparts when using a `ModelForm`):
> CharField ------> CharField with max_length set to the model
field’s max_length and empty_value set to None if null=True.
> TextField ------> CharField with widget=forms.Textarea
Please note that both `CharField` and `TextField` model fields map to a
`CharField` form field, they just have different configuration.

2. The feature that you request (`empty_value` being automatically set to
`None` for `TextField`) can be easily achieved by adding this to your
model form definition:
{{{#!python
my_text_field = forms.CharField(required=False, empty_value=None,
widget=forms.Textarea)
}}}

3. The `empty_value` feature for `CharField` was implemented when solving
ticket #4136. I can't see an explicit conversation about supporting (or
not) the new parameter for `TextField`, which makes me think this was just
missed in that work (due to the focus in `CharField`).

Because of all the above, at first I was inclined to accept this ticket,
since I agree that this is definitely a useful mechanism to deal with the
duality `None`/empty strings for these fields; and from my investigation
there are no duplicate reports nor previous discussion about this. But,
OTOH, making this change would mean effectively doing a backward
incompatible change to the behavior of `TextField` when used in a
`ModelForm`, and I don't see a way that we could provide a deprecation
path to migrate code that would, at the same time, allow for the
deprecation to be "solved" and stop alerting during the whole period of
deprecation.

Given the above, I think that the correct resolution for this ticket is
`wontfix`, but if you disagree, I encourage you to propose and discuss
this proposal with the community and gain consensus to make this change.
To do that, please start a new conversation on the
[https://forum.djangoproject.com/c/internals/5 Django Forum], where you'll
reach a broader audience and receive additional feedback.

I'll close the ticket for now, but if the community agrees with the
proposal, please return to this ticket and reference the forum discussion
so we can re-open it. For more information, please refer to
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features].
--
Ticket URL: <https://code.djangoproject.com/ticket/35726#comment:1>