#36725: Add documentation for HTML form field equivalents to Django form fields
-------------------------------+--------------------------------------
Reporter: Quinn-beep | Owner: (none)
Type: New feature | Status: closed
Component: Documentation | Version: 5.2
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Jacob Walls):
* component: Forms => Documentation
* resolution: => wontfix
* status: new => closed
* type: Cleanup/optimization => New feature
Comment:
Thanks for the idea.
> Currently, Django’s documentation explains the mapping between model
fields and form fields, but it doesn’t provide a clear reference showing
how Django form fields correspond to standard HTML form elements.
I would qualify that statement by saying that the mapping from form fields
to HTML is described in a few places (e.g. "In most cases, the field will
have a sensible default widget.") -- and that the default widgets are
listed here, by field:
https://docs.djangoproject.com/en/5.2/ref/forms/fields/#built-in-field-
classes
In terms of discoverability, we already have a table like you describe
mapping model fields to form fields, so I take it that the issue we're
discussing is that it takes two clicks (one to get to the default widget
("Default widget: EmailInput"), and another to get to the default input
("Renders as: <input type="email" ...>"), making "reverse lookups"
tedious:
https://docs.djangoproject.com/en/5.2/topics/forms/modelforms/#field-types
Instead of creating a new table, it would be better to consider extending
that table with a third column for default widget, to save one of the two
clicks.
But then how to deal with complexity like this:
{{{
class DecimalField(**kwargs)
Default widget: NumberInput when Field.localize is False, else TextInput.
}}}
Then, I'm not sure how much value the reverse lookup provides. You can't
backsolve from a `<select>` to a `ChoiceField` to a model field (if it's
not a `ModelChoiceField`). And the reverse lookup is not so hard from the
existing two-column table. And it will get noisy, e.g. 8 fields have
"Default widget: TextInput".
I'm not opposed to something in principle here, I'm just not sure I can
judge feasibility without seeing a proof of concept. Marking `wontfix`
pending a proof of concept.
--
Ticket URL: <https://code.djangoproject.com/ticket/36725#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 visit
https://groups.google.com/d/msgid/django-updates/0107019a73be1917-22286ac6-09a4-403f-ad84-4dcc34598180-000000%40eu-central-1.amazonses.com.
