One comment on ValidationErrors: When I've done these types of things in the past, I've typically returned two levels of validations messages: warnings and errors. An error indicates that the attempted save will fail (i.e. it would either cause a an object to be saved in an invalid state or it would violate a DB constraint and throw an exception in the backend). A warning would not result in a failure but is still worthy of notifying the user, but there are cases where its OK so its not identified as an error.
An example with a user registration form: user id: first name: last name: password: confirm password: Errors: - user id cannot be blank - user id already exists - password and confirmation do not match Warnings - first/last name not set - password blank - password shorter than suggested length And the logic I'll typically have is - if errors exist then redisplay form with errors and ask user to fix and resubmit - if no errors but some warnings, redisplay form with warnings and ask user to fix _or_confirm_save_with_warnings_ - if no errors and no warnings, just save as usual The reason I point this out is that I like to centralize the logic where the validation rules live - I don't want errors checked for in one place and warnings in another (as others have pointed out, I want ALL validation messages generated at once and then displayed in the form). So I'd suggest a ValidationException that has an errors dict, a warnings dict and possibly a form (or a very easy way to create a form from the exception). -Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
