[Pulling together quotes from a few messages] On Aug 24, 2006, at 2:21 PM, Brantley Harris wrote: > My problem with Joseph's proposal is that I believe it to be too tied > to the concept of the Model. Idealy, the Form/Manipulator should not > really have anything to do with a Model, except perhaps in the > finalization, like in .save().
The way I read it, it doesn't -- a Form can delegate to a model for validation and saving, but doesn't have to. > Also it doesn't end up actually leveraging model-validation. You'd > have to define the validation twice, once in the Model, and then once > in Field. But leveraging on the Model validation turns out to be > rather tricky anyway, even in my proposal. Again, the way I see it would be that Form.validate() would delegate to Model.validate(), iff that Form represents a Model. For custom forms, validate() would delegate differently. Or am I missing something? > The whole raising a Form thing is just a shocking idea. Which, right there, is what I'm opposed to it. Often there's a reason why things are usually done one way, and I don't want to break from the standard way of using exceptions. Having a function raise a Form object as an exception is just strange (to me, at least), and strangeness is *not* what I'm looking for in form processing. On Aug 25, 2006, at 7:04 AM, DavidA wrote: > 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. Yes! This is something that I forgot about -- we've wanted to add validation warnings to Django as long as I can remember. > 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). This sounds like a reasonable idea to me... Jacob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
