> ModelForm has a save() method that saves the model. It is reasonable
> to assume that if the form is valid, the save() method call should
> succeed, that's why the entire model is validated.
mf.is_valid() I have understood as validation strictly on the included
fields in the form. I abuse this "feature". Once I know that
something has been done validly by the user, I can bring into motion
all kinds of things. As you can see all of these forms and their ilk
are intentionally excluding known required fields.
class MinimalContactForm(forms.ModelForm):
class Meta:
model = Contact
fields = ('first', 'm', 'last')
class PrimaryContactForm(forms.ModelForm):
class Meta:
model = Contact
exclude = ('user','primary', 'address', 'email')
class ContactForm(forms.ModelForm):
class Meta:
model = Contact
exclude = ('user',)
I know that you know what I'm saying, so let's see
> We could create a PartialModelForm, that would have save() method only
> when editing (and not adding) models and have other method (or
> enforced commit=False) for retrieval of the partial model. This form
> would only call validation on the modelfields that are part of the
> form (not being excluded). This is the behavior I understand everybody
> expects from ModelForm, so, for backwards compatibility, we could call
> it just ModelForm.
not entirely sure what you mean
> only when editing (and not adding) models and have other method (or
> enforced commit=False) for retrieval of the partial model
.
> Also please mind that it could prove difficult to do half the
> validation in one place and other fields elsewhere without a form.
> Models, as opposed to forms, don't have a state in sense of
> validated/raw and they don't track changes to their fields' data.
> That's why validation is run every time and the results are not cached
> on the instance.
>
> Few quick questions to get some ideas:
>
> 1) If editing a model (passed an instance parameter to __init__), even
> with a partial form, do you expect model.full_validate being called?
>
> 2) Are you OK with ripping save(commit=False) functionality to some
> other method? (current functionality can stay with a deprecation
> warning for example)
I wouldn't like to see that idiom changed. We can create another attr
on the form but leave is_valid()?
> 3) Would you want errors raised in model validation after it being
> created by a form (commit=False) to appear on the form?
I suppose that I have been guilty of taking advantage of modelforms to
an extreme degree. I don't picture needing model validation on my
modelforms right now. I sometimes have a bunch of small forms (if the
case needs) like:
<h3>Applicant information</h3>
{{form|as_uni_form}}
{{profile_form|as_uni_form}}
<h4>How may we contact you?</h4>
{{contact_form|as_uni_form}}
<h4>How did you hear about us?</h4>
{{hear_about|as_uni_form}}
<h4>Terms and Conditions</h4>
{{tos_form|as_uni_form}}
if form.is_valid() and profile_form.is_valid()...:
... do magic to create user ...
add the required user field to the other objects with commit=False
idiom
Perhaps in this way I am also abusing the relational db. But, I
always find occasion to add required fields (often FK to the other
modelforms) after I know the form "is
valid" (UnresolvableValidationError).
But, I would like another attr, so I could call modelform.model_errors
() or modelform.model_is_valid() or something. Just plugging my own
self interest here though really.
I would like to see everything that I use behave exactly as I have
come to know it and then see other new features popping up around
that.
>
> on subject of inlines:
> 1) Is it acceptable to create a model and not it's inlines in the
> admin if the modelform validates but the inlines don't?
>
> 2) How can we limit people's validation code to avoid validating FKs
> in inlines since users can (and should) create their own validation
> logic on Models? Especially when we try and treat admin as "just a
> cool app" and not something people should really design for.
>
> 3) How would you feel on creating an option to enable behavior (1) )
> and document that models with side effects in their save and delete
> should really go for that?
>
> 4) Making 3) the default and enable switching it off if people want
> their admin page to save atomically.
>
> Please let me know what you think
I don't really know enough about the internals of the admin to say
much about that.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
