Thank you for the replay Florian, I will think about what you said that Django shouldn't make any assumptions about fields outside the form, but my intuition tells me that there are more staff which we could be retrieved from the ModelForm's.
Some of my initial thoughts: If the ModelForm doesn't care about anything outside the defined fields, then this is just a regular Form, the only difference is that it can use Models as a short-cut to be defined. (ModelFormFactory?) If we agree on this (I'm perfectly fine to agree that this could be the scope of a ModelForm), then I would probably not expect to see a method like `form.save()`, just force me to use `form.cleaned_data` to build my instance, make it more clear that the ModelForm is more like a FormFactory class instead of throwing me options like `commit=False`. I believe this could save a lot of headache to people. If there is no guarantee that an instance cannot be saved after the form has been validated, then do not give me an option to shoot myself into the foot. However, why I could expect the ModelForm to be something more... This is a ModelForm, yes it may sit into the `forms` namespace, but still its half `Model` and a half `Form`, pretending to be a form-only class is pity for something that do so much heavy-lifting to remove all the tedious tasks from us (love it for this). Use all the metadata we have into the model to validate the instance. My only concern here actually is not that we didn't know what will happen (I think we know that), but how to show the user that the developer got messed up, i.e. how to render an error for a field that is not rendered to the user? Should this error be propagated to a NON-FIELD error or something else? I don't know yet, maybe no, maybe this field should not be validated and lead to a server error. But, however, in the scope of the problem shown here (a multi-field-level unique constrain) this is not an issue, because this is not a field-level error, this is a multi-field-unique constrains, so maybe the only thing that needs to be changes, is to stop respecting the excluded fields when validating multi-field level unique constrains? I feel its perfectly fine to ask for a complete model instance at this stage of the validation process (lots of methods got passed from the beginning - form.clean() and instance.clean()). I would love to see more opinions on the topic. Thank you. On Saturday, October 7, 2017 at 1:55:24 PM UTC+3, Florian Apolloner wrote: > > I think the current behaviour is correct. Django shouldn't make any > assumptions about fields not in the form since it doesn't know what will > happen… In that sense I disagree with the statement: > > > From my point of view when I define a ModelForm I imagine that I have to > only explain what the user needs to see when the form gets rendered. > > To get what you want use something along the lines of: > https://gist.github.com/apollo13/ef72035c5f864174ad3c968dec60d88a > > 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/99469dcc-5850-4168-b490-2ca7accf8ebc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
