Another suggestion: could you include the field on the form but use a HiddenInput widget?
On Thursday, July 3, 2014 9:03:25 AM UTC-4, Jon Dufresne wrote: > > On Thu, Jul 3, 2014 at 1:12 AM, Florian Apolloner <[email protected] > <javascript:>> 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 [email protected]. To post to this group, send email to [email protected]. 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/f7f4eb90-b25d-4d9a-a06f-3c8b9568dd3a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
