+1 on a better way to do field errors. An alternate would be to implement a method that does this.
def field_error(self, name, error): > self._errors = self._errors or ErrorDict() > self._errors.setdefault(name, ErrorList()) > self._errors[name].append(error) Having to raise a ValidationError would prevent you from creating multiple field errors from within `clean`. On Monday, August 19, 2013 6:58:25 PM UTC-6, Simon Litchfield wrote: > > Lack of clean control over field-specific form errors is an issue that has > been raised and discussed many times over the years, but still the solution > seems pretty inadequate. We're even directing people hack around with > _errors and making excuses for it in the documentation. > > https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors > > What about an optional kwarg on ValidationError? Eg, raise > forms.ValidationError('This field is seriously not cool', field='myfield'). > Current > behaviour as-is. > -- 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.
