On Aug 22, 2013, at 4:29 AM, Wim Feijen <[email protected]> wrote: > How about: > > form.add_errors(dictionary)
That's actually supported, although you need to nullify `field` explicitly: `form.add_errors(None, dictionary)`. It's mostly used internally; I'm not sure it's really useful to document, since most likely you will need to construct that dictionary by iterating through a series of conditions and you could call `add_errors` each time. I did a quick poll on IRC and it looks like the singular name `Form.add_error(self, field, error)` is more popular because that should be the most common case, although `error` will still accept all kind of constructs: single error, list of errors, dict of errors, simple strings and `ValidationError` instances. On Aug 21, 2013, at 7:31 AM, Simon Litchfield <[email protected]> wrote: > An improvement for sure. Any reason it can't be a little more pythonic, ie > using optional kwargs etc? I'm not too sure what you mean, could you paste some pseudocode? > My only concern is in having two ways of achieving the same thing. If the > latter is simpler and more flexible, does this place our entire > ValidationError approach to handling form and model errors in question? Hmmm. > Maybe we can come back to that later :-/ The two approaches complement each other. By design (loose coupling) you can't access `Form._errors` through most of the validation process: `Field.clean()`, `Validator` or validation at the `Model` layer for `ModelForm`. Raising `ValidationError` is your only option here. `Form.add_error()` is just a more elegant solution to fiddling with `Form._errors`. It comes in handy when you want to validate "after the fact", like adding errors from a view or adding errors to specific fields after their dedicated validation cycle is done (in other words, from `Form.clean()`). Raising an exception was never an option here hence why we documented all the shortcomings of modifying `_errors` directly. The only overlap is `Form.clean_<fieldname>()`, but even here `Form.add_error()` wouldn't be too practical compared to raising an exception since you would have to manually provide the field name. Also, as I mentioned in a previous post, if https://github.com/django/django/pull/1483 pass, it will become rewarding to provide metadata to errors (codes, and params), and the carrier for such metadata is `ValidationError`. Ideally you would do `self.add_error('fieldname', ValidationError('message', code='code'))`; so if you are in `Form.clean_<fieldname>()` you might as well raise the exception... -- Loic -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
