[Django] #22383: Django form auto add requried tag
Django
---------------------------------+--------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------
Hi,
When we use django forms, it would be nice if it automatically add the
required tag to the input fields which are required for database entry,
this way the user won't even be able to submit the form, instead of
getting back the form with errors that "missing field" .
--
Ticket URL: <https://code.djangoproject.com/ticket/22383>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 1.6
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 anubhav9042):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Sounds sensible to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:1>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by anubhav9042):
* cc: anubhav9042@… (added)
* version: 1.6 => master
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:2>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Are there any backwards compatibility concerns? For example, what if
someone is not using an HTML5 doctype?
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:3>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
Replying to [comment:3 timo]:
> Are there any backwards compatibility concerns? For example, what if
someone is not using an HTML5 doctype?
I don't think there is any problem, if `<!DOCTYPE html>` is not used, then
form does not gets submitted just as the case when doctype is used. The
only difference is that the help message does not pops out.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:4>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
Loic suggested that this would be good as an optional feature.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:5>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
I did some work here:
https://github.com/coder9042/django/compare/ticket_22383?expand=1
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:6>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
A form attribute doesn't seem like the most elegant solution, but it's
consistent with other form attributes like `Form.required_css_class` and I
cannot think of a better way. A setting is obviously a no-go...
I suggest calling it `use_required_attribute` instead of
`required_html_tag`. IMO, I think most people would want this behavior so
the attribute could default to `True` and people could opt-out by setting
it to `False`. It would just need to be noted in the release notes as a
backwards incompatible change.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:7>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
Ok.
Wouldn't it be better to provide people to choose whether they want to go
the conventional way or other just like in case of `required_css_class`
But also as Tim Graham says "I don't think the feature will be used very
much if it isn't turned on by default." also seems valid situation.
Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:8>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by anubhav9042):
* status: new => assigned
* owner: nobody => anubhav9042
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:9>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
Having the `required` HTML5 attribute changes the browser behavior
significantly. If we want it on by default, then I think we need a
deprecation period, maybe the strategy used for #20684 can be applied
here?
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:10>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
Replying to [comment:10 loic84]:
> Having the `required` HTML5 attribute changes the browser behavior
significantly. If we want it on by default, then I think we need a
deprecation period, maybe the strategy used for #20684 can be applied
here?
I like this approach.
We can add the optional behaviour now with a warning that it would be made
default in 1.9.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:11>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
So sum up what's been discussed on IRC:
I didn't suggest a quick deprecation cycle, but a normal deprecation cycle
based on the value of a boolean. (btw, even if we did a faster
deprecation, that would be using a subclass of DeprecationWarning, not
just Warning)
To deprecate you could do:
{{{
class form.Form(object):
#...
use_required_attribute = None
class BoundField(object):
#...
def as_widget():
if self.form.use_required_attribute is None:
warnings.warn()
elif form.use_required_attribute:
attrs['required'] = True
}}}
Now what happens next depends on the actual goal, do we want to use
`use_required_attribute` as a permanent way to control this feature, or as
a mere deprecation tool.
Personally I'm not thrilled by this feature, although I know lot of people
will want it, so I'd like to keep the switch.
Another point of interest, right now there is no way to tell a form that
it should render as HTML4 or HTML5. When we discussed #20684 we
acknowledged that if someone really cared about HTML4 validation, they
could use `required="required"` instead of `required=True`, but if this
becomes the default and we kill `use_required_attribute`, we'd be
outputting HTML5.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:12>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
I am in favor for accelerated deprecation, although I don't know if it'll
allowed here.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:13>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anubhav9042):
https://groups.google.com/forum/#!topic/django-developers/obw18wSc4xU
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:14>
Django
entry
---------------------------------+---------------------------------------
Reporter: abhishek.garg@… | Owner: anubhav9042
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by melinath):
FTR, there are (potentially) backwards-compatibility issues regarding the
"required" attribute and formsets. See https://github.com/gregmuellegger
/django-floppyforms/issues/75
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:15>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* owner: anubhav9042 =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:16>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* cc: jon.dufresne@… (added)
* has_patch: 0 => 1
Comment:
Implemented {{{use_required_attribute}}} as described above.
https://github.com/django/django/pull/6341
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:17>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I fear the deprecation will be quite annoying if every form in a project
needs to be modified to silence all warnings. I wonder if template-based
widget rendering (#15667) might ease this change. A project could provide
custom widget templates if they don't want the `required` attribute (or if
they want `required='required'`.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:18>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jdufresne):
> I fear the deprecation will be quite annoying if every form in a project
needs to be modified to silence all warnings.
Alternatively, a project could monkey patch the base form class to set a
`True`/`False` default for `use_required_attribute`. I could document this
technique if you agree with the approach.
> A project could provide custom widget templates if they don't want the
required attribute (or if they want required='required'.
Wouldn't this still require a deprecation path such that the `required`
attribute isn't set by default until a future version? In this scenario
where would warning be produced? Would the project need to override all
templates to squelch all warnings?
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:19>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I guess I'm not sure if a deprecation path provides more value than making
a backwards-incompatible change. For example, if we expect a majority of
projects to adopt this change, then a deprecation will require every
Django project to silence the warning instead of a subset of users to opt-
out. Maybe you could try to get some other opinions on the
[https://groups.google.com/d/topic/django-
developers/obw18wSc4xU/discussion mailing list thread].
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:20>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jdufresne):
> I guess I'm not sure if a deprecation path provides more value than
making a backwards-incompatible change.
I've added alternative PR that skips the deprecation cycle:
<https://github.com/django/django/pull/6352>. It uses the same
`Form.use_required_attribute` approach as the previous PR.
I'll follow through with mailing list to get other opinions.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:21>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
New [https://groups.google.com/d/topic/django-
developers/OEcRKkV_6cw/discussion django-developers thread].
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:22>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jdufresne):
From Alex Riina in the thread:
> What's the plan for formsets with extra?
>
> I could see the required only getting applied to the first min forms but
I'm not sure there is an actual workable case there. It seems like it will
get too messy with adding and deleting at the same time.
>
> If can_delete is false and extra is 0, it seems like the required
attribute could at least be used. Because of this, I think it should
probably be an initialization argument, default to false, or be overridden
when constructing forms in formsets.
Updated PR based on this feedback. The required attribute is no longer
applied to formsets by default. Can now override the
`Form.use_required_attribute` value by passing the kwarg
`use_required_attribute` to the form's constructor.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:23>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: 0 => 1
Comment:
For the record, Loic dropped his suggestion of a deprecation cycle: "I
guess people can easily add `novalidate` to their `<form>` to opt out of
that".
I've left some comments for improvement on the pull request.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:24>
Django
entry
---------------------------------+------------------------------------
Reporter: abhishek.garg@… | Owner:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* needs_better_patch: 1 => 0
Comment:
> I've left some comments for improvement on the pull request.
I have addressed all comments in the PR. All additional feedback is
welcome. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:25>
Django
entry
Reporter: abhishek.garg@… | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:26>
Django
entry
-------------------------------------+-------------------------------------
| Graham <timograham@…>
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: => Tim Graham <timograham@…>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"ec6121693f112ae33b653b4364e812722d2eb567" ec61216]:
{{{
#!CommitTicketReference repository=""
revision="ec6121693f112ae33b653b4364e812722d2eb567"
Fixed #22383 -- Added support for HTML5 required attribute on required
form fields.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22383#comment:27>