#24191 closed New feature (fixed)
form.changed_data appears to be undocumented
Reported by: | Raphaël Hertzog | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | belorn@…, alasdair@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
https://docs.djangoproject.com/en/1.7/ref/forms/api/ does not document form.changed_data
Yet this field appears to be widely used... it would be nice to see this fixed.
This has been reported by Björn Påhlsson to Debian in https://bugs.debian.org/616331 (I put him in CC).
Change History (9)
comment:1 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 1.7 → master |
comment:2 by , 9 years ago
I have created a pull request https://github.com/django/django/pull/4768 which documents form.changed_data.
I haven't addressed the comment that tim refers to. Changing the implementation of has_changed
to use a hidden field would have backwards incompatibility implications for
form.has_changed()
(which is documented) as well.
I may have misunderstood the suggestion in the comments, but am not sure that the the hidden field approach is better. Not every form is instantiated from a request.POST
or request.GET that contains a hidden field.
comment:3 by , 9 years ago
Cc: | added |
---|---|
Has patch: | set |
follow-up: 5 comment:4 by , 9 years ago
Let's remove that comment in the code then. Same PR separate commit would be fine.
comment:5 by , 9 years ago
Replying to timgraham:
Let's remove that comment in the code then. Same PR separate commit would be fine.
I've added another commit to the pull request that removes the comment.
Just because something is "widely used" isn't a justification for making it a public API, but we recently documented
Form.has_changed()
so it probably makes sense to document this as well. This method relies onfield.show_hidden_initial
which also isn't documented so we might want to consider that as well.We should likely address the comment in the
changed_data
propertyXXX: For now we're asking the individual fields ...
before documenting this though as if we make that change it might be easier to do so before documenting in case there are any backwards compatibility concerns.