Wow - I just realised that we have been losing data for sometime on our web
platform since there were some fields in the ModelForm that were hidden and
not being sent. They were all being overwritten as blank values. Thank God,
we use django-reversion to track changes. Will take us sometime to recover
the data though.
Its been 6 years since the last post on this thread. Has anyone able to
come up with a smart solution yet? (apart from not using Model Forms)
thanks
Anupam
On Friday, January 13, 2012 at 9:09:02 PM UTC+5:30, Mark Lavin wrote:
>
> I think Ian demonstrated exactly why this should not go in and that is not
> all forms are ModelForms. Imagine writing a REST API which allows for an
> optional format parameter for GET requests which is validated by a Django
> form. With the inclusion of this proposal all clients would be forced to
> specify the format in the GET (even if left blank) or else the form won't
> validate. That's not much of an optional field and a large backwards
> incompatibility.
>
> On Fri, Jan 13, 2012 at 10:20 AM, Daniel Sokolowski <
> daniel.s...@klinsight.com <javascript:>> wrote:
>
>> 1. How does this proposal effect default values specified on model
>> fields? (ModelForm processing)
>> 2. Forgive my ignorance but who has the final say if it goes in or not?
>> And since it should be a yes what's next?
>>
>> On Thu, Jan 12, 2012 at 8:40 PM, Tai Lee <real....@mrmachine.net
>> <javascript:>> wrote:
>>
>>> Ian,
>>>
>>> I agree that there are a lot of different ways that form data can be
>>> submitted to Django, including near endless combinations of multiple
>>> Django forms, multiple HTML forms, AJAX, etc.
>>>
>>> If we reduce the scope of our discussion and consider only a Django
>>> form (forgetting HTML forms and AJAX) and two possible scenarios:
>>>
>>> 1. Partial form data is bound to a Django form, and it is not expected
>>> to result in a call to the form's `save()` method and a change to the
>>> database. It is only intended to examine the form's validation state
>>> relating to the partial data that is bound to the form. In this case,
>>> the proposed change should have no impact.
>>>
>>> 2. Full form data is bound to a form, and it IS expected to validate
>>> and result in a call to the form's `save()` method and a change to the
>>> database. In this case, why would we ever want to assume that a
>>> character field which has no bound data, is actually bound to an empty
>>> string?
>>>
>>> This is a dangerous assumption, I think. If we intend to obtain
>>> complete data from the user, bind it to a form and save it to the
>>> database, we should be sure (as much as we can be) that the data is
>>> actually complete.
>>>
>>> Take the following pure Django example:
>>>
>>> {{{
>>> class Profile(models.Model):
>>> first_name = models.CharField(blank=True, max_length=50)
>>> last_name = models.CharField(blank=True, max_length=50)
>>> address = models.CharField(blank=True, max_length=50)
>>>
>>> class ProfileForm(ModelForm):
>>> class Meta:
>>> model = Profile
>>>
>>> profile = Profile.objects.create(first_name='Tai', last_name='Lee',
>>> address='Sydney')
>>> form = ProfileForm({}, instance=profile)
>>> if form.is_valid():
>>> form.save()
>>> }}}
>>>
>>> The profile will have no first name, last name or address. The form
>>> will produce no validation errors and will save the updated model to
>>> the database.
>>>
>>> This is very surprising and counter-intuitive to me.
>>>
>>> I think the only time we could safely make the assumption that fields
>>> with empty string values will be omitted by the UA is when we are
>>> confident that the source of the form data also makes a similar
>>> assumption that the back-end will re-normalise those missing fields
>>> back to an empty string.
>>>
>>> I'd be surprised if any UAs actually do make that assumption, because
>>> the way Django treats missing character fields does not appear to be
>>> based on any spec, and Django is not the only form processing back-end
>>> (or even the most popular one).
>>>
>>> I'm not sure I follow your simplest case example of one HTML form in a
>>> browser window and one Django Form in a view. If optional fields are
>>> left off the HTML form deliberately, without change the Form class or
>>> the view code, this is exactly when data loss will currently occur. I
>>> think you are confusing optional as in "may not be specified by the
>>> user" with optional as in "may not be processed by the form"?
>>>
>>> Cheers.
>>> Tai.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To post to this group, send email to django-d...@googlegroups.com
>>> <javascript:>.
>>> To unsubscribe from this group, send email to
>>> django-develop...@googlegroups.com <javascript:>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-d...@googlegroups.com
>> <javascript:>.
>> To unsubscribe from this group, send email to
>> django-develop...@googlegroups.com <javascript:>.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
--
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/6efc767e-110e-44c4-8330-291d96c2151f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
