[Django] #21654: Better name for Form.as_data()
Django
-------------------------------+--------------------
Reporter: selwin | Owner: nobody
Type: Uncategorized | Status: new
Component: Forms | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
From Django 1.7's release notes:
The dict-like attribute errors now has two new methods as_data() and
as_json(). The former returns a dict that maps fields to their original
errors, complete with all metadata (error code and params), the latter
returns the errors serialized as json.
Is `form.as_dict()` a better name than `form.as_data()`?
--
Ticket URL: <https://code.djangoproject.com/ticket/21654>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: selwin | Owner: nobody
Type: Uncategorized | Status: new
Component: Forms | Version: master
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 selwin):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Sorry, I meant `form.errors.as_dict()`
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: selwin | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* type: Uncategorized => Cleanup/optimization
Old description:
> From Django 1.7's release notes:
>
> The dict-like attribute errors now has two new methods as_data() and
> as_json(). The former returns a dict that maps fields to their original
> errors, complete with all metadata (error code and params), the latter
> returns the errors serialized as json.
>
> Is `form.as_dict()` a better name than `form.as_data()`?
New description:
From Django 1.7's release notes:
The dict-like attribute errors now has two new methods as_data() and
as_json(). The former returns a dict that maps fields to their original
errors, complete with all metadata (error code and params), the latter
returns the errors serialized as json.
Is `form.errors.as_dict()` a better name than `form.errors.as_data()`?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
FWIW, I initially called it `as_dict()`, but `form.errors` is a `dict`, so
technically that translates to `dict.as_dict()`.
@mjtamlyn pointed out this issue in
https://github.com/django/django/pull/1406#issuecomment-21705685 and I
agreed with his argument.
It's also worth noting that `as_data()` is a lower level method, if you
just want to access the rendered error messages, you should directly use
`form.errors` as a `dict`.
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
Ah ok, I understand your reasoning. If we cast technical implementation
aside though, I think users will find `form.errors.as_dict()` more
readable as it perfectly describes what the method does (getting form
errors in dictionary format).
No strong opinions on this though :)
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:4>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by mjtamlyn):
The problem with `as_dict()` is that it is already a dict. I think users
are likely to overuse an `as_dict()` method when what they already have
(an `ErrorDict`) would suffice.
Am I correct in thinking that the return of `as_data()` consists of just
dicts, lists and strings (i.e. no `ErrorDict`, `ErrorList` objects)? If so
then perhaps we can steal a name from DRF and call it `to_native()` or
`as_native()`?
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:5>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
No strong opinion on my side either. But I think it's important to stress
that form.errors is already just that: "form errors in dictionary format",
albeit already rendered (translated and formatted with params).
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:6>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by loic84):
* cc: loic@… (added)
Comment:
Somehow missed @mjtamlyn's response. as_data() returns a dict (native) of
list (native) of ValidationError. form.errrors on the other hand is a
dict (ErrorDict) of list (ErrorList) of string.
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:7>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization | Version: master
Component: Forms | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Should we perhaps clarify the reasoning with a documentation update so
others don't ask the same question?
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:8>
Django
--------------------------------------+------------------------------------
Reporter: selwin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Changes (by bmispelon):
* stage: Unreviewed => Accepted
* easy: 0 => 1
Comment:
I agree with Tim that a documentation update would help clear up the
confusion.
Why would a user want to use `form.errors.as_data()` instead of just
`form.errors`; is there a use-case for it?
I'm accepting the ticket on this basis.
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:9>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by loic84):
- `as_data()` returns the `ValidationError` instances, you need that if
you want to do anything meaningful with the errors other than just
displaying it.
- `form.errors` returns the **rendered** errors which are basically blobs
of text. At that point all the metadata is gone, no error code, no params,
and the string has already been translated. All you can do is display this
text; you can't manipulate it since you can't identify the individual
errors anymore, especially if translation is involved.
Ideally `form.errors` would have always returned `ValidationError`
instances and `as_data()` wouldn't exist, but that would have been
backward incompatible, so we had to do it the other way around.
Use-cases include, serializing the errors (say in xml or a custom json),
rewrite or remove a given error message, etc. Basically, anytime you need
an answer to the question "what is this error message?".
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:10>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
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 timo):
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:11>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* component: Forms => Documentation
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:12>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by loic84):
* has_patch: 0 => 1
Comment:
PR https://github.com/django/django/pull/2273.
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:13>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: closed
Component: Documentation | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"2e4200b5c7cb4887b7034bb5dcbbd354e4698f27"]:
{{{
#!CommitTicketReference repository=""
revision="2e4200b5c7cb4887b7034bb5dcbbd354e4698f27"
Fixed #21654 -- Documented a use-case for Form.errors.as_data().
Thanks selwin for the suggestion.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21654#comment:14>