On 11/18/2014 12:34 PM, Alasdair Nicol wrote:
> On 17/11/14 16:53, Carl Meyer wrote:
>> (Personally I think it would be better to document the same technique
>> for both Model.clean() and Form.clean(), because I don't think
>> Form.add_error() is significantly easier, and it breaks the API
>> consistency of "always flag a validation problem by raising
>> ValidationError", but I guess that's a larger discussion.)
>
> I've been updating a codebase to Django 1.7 this week. Personally, I
> find the add_error API to be more concise when you don't want to raise
> an exception immediately.
>
> class MyForm(forms.Form):
> def clean():
> if check1():
> self.add_error('field1', 'error message')
> if check2():
> self.add_error('field2', 'error message')
>
> In my models' clean methods, I have to keep track of the errors as I go
> along.
>
> class MyModel(models.Model):
> def clean():
> errors = {}
> if check1():
> errors['field1'] = 'error message'
> if check2():
> errors['field2'] = 'error message'
> if errors:
> raise ValidationError(errors)
>
> Having said that, it's not that much more difficult, only 3 extra lines
> of code in this case. API consistency is a good argument for documenting
> the ValidationError(dict) approach in both places.Yes, the add_error() API is slightly less verbose if you have multiple different errors you may want to flag. I don't think that difference is worth having to remember two different ways to do it, but I don't really feel strongly enough about it to push for what would essentially amount to deprecating `Form.add_error()`. I am satisfied as long as `raise ValidationError(dict)` continues to work in both places, so I can use it in my code :-) Carl
signature.asc
Description: OpenPGP digital signature
