Re: Digest for django-developers@googlegroups.com - 3 Messages in 1 Topic
> Adrian Holovaty Jan 13 12:07PM -0600 > The ultimate solution is: don't use model forms. I never use them for > anything, precisely because of things like this, where the framework > is trying to do too much behind the scenes. It's too magical for my > tastes, and while I understand why we added it to the framework, I see > it as a crutch for lazy developers. C'mon, it's not a lot of work to > create a "normal" (non-model) form class and pass its cleaned data to > a model's save() method. > > End rant. :-) I pretty much agree with Adrian. I use ModelForms when I'm grinding out stuff fast, but for real, detail work, I rely on normal forms.Forms. My reasons match Adrian's reasons. I use them as a crutch, but the magic can hurt at the worst time. So when I have time, I refactor to make thing simpler and less atomic. I leave all the magic stuff to smart people. ;) -- 'Knowledge is Power' Daniel Greenfeld http://pydanny.blogspot.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Don't assume that missing fields from POST data are equal to an empty string value.
> The "ProfileForm({}, instance=profile)" is
> clearly passing in empty data (the empty dictionary), and it makes
> sense that Django would see the empty data, then determine that empty
> data is allowed on the fields (blank=True) and set those fields to
> empty data. If you want to avoid this, you have two options: don't use
> "blank=True," or don't use a model form.
I agree with Adrian. Django doesn't have control over all user agents,
and we know that most of them already behave in exactly the way the
RFC specifies (not sending anything for blank fields) in at least some
cases (checkboxes and radioboxes). I don't think writing code to
special-case everything else is the right solution.
If the person writing your form leaves fields off that should be
present and it results in data loss, I'd treat that like any other
code bug - we don't special case to save the data from views that
throw a 500 because you wrote invalid Python, so I don't see why we
should add a special case for when you might write incorrect HTML.
-Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Don't assume that missing fields from POST data are equal to an empty string value.
On Thu, Jan 12, 2012 at 7:40 PM, Tai Lee wrote:
> 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.
The ultimate solution is: don't use model forms. I never use them for
anything, precisely because of things like this, where the framework
is trying to do too much behind the scenes. It's too magical for my
tastes, and while I understand why we added it to the framework, I see
it as a crutch for lazy developers. C'mon, it's not a lot of work to
create a "normal" (non-model) form class and pass its cleaned data to
a model's save() method.
End rant. :-)
Thanks for writing out this example, Tai. I disagree and do not see it
as counterintuitive. The "ProfileForm({}, instance=profile)" is
clearly passing in empty data (the empty dictionary), and it makes
sense that Django would see the empty data, then determine that empty
data is allowed on the fields (blank=True) and set those fields to
empty data. If you want to avoid this, you have two options: don't use
"blank=True," or don't use a model form.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Don't assume that missing fields from POST data are equal to an empty string value.
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 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-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
