Code

Opened 4 months ago

Closed 2 months ago

#21654 closed Cleanup/optimization (fixed)

Document a use-case for `Form.errors.as_data()`

Reported by: selwin Owned by: nobody
Component: Documentation Version: master
Severity: Normal Keywords:
Cc: loic@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by charettes)

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()?

Attachments (0)

Change History (14)

comment:1 Changed 4 months ago by selwin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Sorry, I meant form.errors.as_dict()

comment:2 Changed 4 months ago by charettes

  • Description modified (diff)
  • Summary changed from Better name for Form.as_data() to Better name for `Form.errors.as_data()`
  • Type changed from Uncategorized to Cleanup/optimization

comment:3 Changed 4 months ago 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.

comment:4 Changed 4 months ago 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 :)

comment:5 Changed 4 months ago 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()?

comment:6 Changed 4 months ago 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).

comment:7 Changed 4 months ago by loic84

  • Cc loic@… added

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.

Last edited 4 months ago by loic84 (previous) (diff)

comment:8 Changed 4 months ago by timo

Should we perhaps clarify the reasoning with a documentation update so others don't ask the same question?

comment:9 Changed 3 months ago by bmispelon

  • Easy pickings set
  • Summary changed from Better name for `Form.errors.as_data()` to Document a use-case for `Form.errors.as_data()`
  • Triage Stage changed from Unreviewed to Accepted

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.

comment:10 Changed 3 months ago 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 them.
  • 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?".

Last edited 3 months ago by loic84 (previous) (diff)

comment:11 Changed 3 months ago by timo

  • Easy pickings unset

comment:12 Changed 3 months ago by timo

  • Component changed from Forms to Documentation

comment:14 Changed 2 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 2e4200b5c7cb4887b7034bb5dcbbd354e4698f27:

Fixed #21654 -- Documented a use-case for Form.errors.as_data().

Thanks selwin for the suggestion.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.