Hi, On Monday, October 9, 2017 at 8:52:53 AM UTC+2, Todor Velichkov wrote: > > Settings values programmatically is a cumulative operation most of the > time, however when its not and things depend on each other (like your > example), then even the docs suggests than one can use the form.clean > method. >
It does? Can you give me a link to that please? If there is some other dependency outside form.cleaned_data I would prefer > to use dependency injection in order to get this data and do the job done. > I'm sorry I just see commit=False as an anti-pattern, because the > validation needs to be repeated after that (as your example in the first > post). > Repeated is a bit overreaching, it also checks new fields… Showing an error message which the user cannot correct is a horrible UX > indeed, but still its a UX, and some people may find it as a better > alternative to a `500 server error page`, where there is no UX at all. Even > a generic message like 'sorry we messed up' would be useful, because the > user data that will be preserved into the form. However, in the example > shown here, this is not even the case, there is something that the user can > do to prevent the error. > The generic error message is something that I supply in some forms of mine where race conditions can happen due to high concurrency. This is why I guard form.save, catch database errors and then use form.add_error to add a generic error message asking for a retry. In the example shown, the user can do something about the error, this is correct, but the default error message would be rather confusing since it would cover a field which is not part of the form. That said, form.save(commit=False) is there and will stay, even if it is just for backwards compatibility. Same goes for the partial validation of the instance, this is just something to many people rely on and changing is not really an option. One could add a new flag to the Meta object ala validate_full_model, but for that to work you will have to tell us a sensible UX approach first. I am opposed to adding something which we agree is horrible just because the alternative (like I've shown) requires a few additional lines of code. Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/250667ec-70f8-4d9b-8813-766ee65ed5ed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
