On Thu, Jul 3, 2014 at 1:12 AM, Florian Apolloner <f.apollo...@gmail.com> wrote: > To me this is no shortfall but expected and good behaviour, including other > fields in the validation (i.e. fields not on the form) would be very > confusing. Where would errors show up?
Right now unique violations show up as non-field errors on the forms with duplicate values. So I my proposal would do the same. > Also, even if we find a place to show > the errors, the user is (usually) in no position to correct them (after all, > there is no field he could change to fix it). I don't follow. In my specific example the user is able to change the "name" field. In my opinion, the form should fail to validate because the _user_ entered "newname" twice, for two different names when they should be unique. The user is in the position to 1) make these conflict and 2) correct them. > I think in your case you > should call model.full_clean() after form validation and handle any unique > errors there… I will certainly experiment with this thanks. Cheers, Jon -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b7_LiNG6LnikpMWwJew_kQZ3J9Hd5%3DsT4sp9Y_m-cd4GA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
