+1 on a loud exception being raised. "Errors should never pass silently. Unless explicitly silenced."
Cheers, AT On Wed, Jan 11, 2012 at 1:29 PM, Daniel Sokolowski < daniel.sokolow...@klinsight.com> wrote: > +1 even though I agree with what Babatunde said I support this change as > anything that minimizes a 'gotchas' during development is very good. I > raether get an exception instead of spending half an hour debuging why my > data is not being saved. Sure once I figure it out I would learn to pay > attention in similar situations in the future but realistically I shouldn't > and nor should the next python/django programmer re-discovering this caveat. > > On Wed, Jan 11, 2012 at 9:11 AM, Babatunde Akinyanmi <tundeba...@gmail.com > > wrote: > >> -1 >> I think a programmer should not specify a field that would contain >> important data as optional in the first place. If the data loss from >> not including it in the form is going to cause problems then it should >> not be optional. >> >> On 1/11/12, Tai Lee <real.hu...@mrmachine.net> wrote: >> > There is a potential for data loss with optional form fields that are >> > (for whatever reason) omitted from an HTML template. >> > >> > For example, if we take an existing model form and template that >> > works, add an optional character field to the model but fail to add a >> > corresponding field to the HTML template (e.g. human error, forgot >> > about a template, didn't tell the template author to make a change, >> > didn't realise a change needed to be made to a template), when that >> > form is submitted Django will assume that the user has provided an >> > empty string value for the missing field and save that to the model, >> > erasing any existing value. This is not a bug, but it is relatively >> > easy to trigger silent and unexpected data loss. >> > >> > I have briefly discussed this with PaulM and dstufft on django-dev, >> > but could did not reach any consensus. >> > >> > RFC1866 [1] says: >> > >> >> The fields are listed in the order they appear in the >> >> document with the name separated from the value by `=' and >> >> the pairs separated from each other by `&'. Fields with null >> >> values may be omitted. In particular, unselected radio >> >> buttons and checkboxes should not appear in the encoded >> >> data, but hidden fields with VALUE attributes present >> >> should. >> > >> > The HTML4 spec at W3C.org [2] says: >> > >> >> Users interact with forms through named controls. >> >> >> >> A control's "control name" is given by its name attribute. The scope of >> >> the >> >> name attribute for a control within a FORM element is the FORM element. >> >> >> >> Each control has both an initial value and a current value, both of >> which >> >> are >> >> character strings. Please consult the definition of each control for >> >> information about initial values and possible constraints on values >> >> imposed by >> >> the control. In general, a control's "initial value" may be specified >> with >> >> the >> >> control element's value attribute. However, the initial value of a >> >> TEXTAREA >> >> element is given by its contents, and the initial value of an OBJECT >> >> element >> >> in a form is determined by the object implementation (i.e., it lies >> >> outside >> >> the scope of this specification). >> >> >> >> The control's "current value" is first set to the initial value. >> >> Thereafter, >> >> the control's current value may be modified through user interaction >> and >> >> scripts. >> >> >> >> A control's initial value does not change. Thus, when a form is reset, >> >> each >> >> control's current value is reset to its initial value. If a control >> does >> >> not >> >> have an initial value, the effect of a form reset on that control is >> >> undefined. >> >> >> >> When a form is submitted for processing, some controls have their name >> >> paired >> >> with their current value and these pairs are submitted with the form. >> >> Those >> >> controls for which name/value pairs are submitted are called successful >> >> controls. >> > >> > as well as [3]: >> > >> >> A successful control is "valid" for submission. Every successful >> control >> >> has >> >> its control name paired with its current value as part of the submitted >> >> form >> >> data set. A successful control must be defined within a FORM element >> and >> >> must >> >> have a control name. >> >> >> >> However: >> >> >> >> * Controls that are disabled cannot be successful. >> >> * If a form contains more than one submit button, only the activated >> >> submit >> >> button is successful. >> >> * All "on" checkboxes may be successful. >> >> * For radio buttons that share the same value of the name attribute, >> only >> >> the >> >> "on" radio button may be successful. >> >> * For menus, the control name is provided by a SELECT element and >> values >> >> are >> >> provided by OPTION elements. Only selected options may be successful. >> >> When >> >> no options are selected, the control is not successful and neither >> the >> >> name >> >> nor any values are submitted to the server when the form is >> submitted. >> >> * The current value of a file select is a list of one or more file >> names. >> >> Upon >> >> submission of the form, the contents of each file are submitted with >> the >> >> rest of the form data. The file contents are packaged according to >> the >> >> form's content type. >> >> * The current value of an object control is determined by the object's >> >> implementation. >> >> >> >> If a control doesn't have a current value when the form is submitted, >> user >> >> agents are not required to treat it as a successful control. >> >> >> >> Furthermore, user agents should not consider the following controls >> >> successful: >> >> >> >> * Reset buttons. >> >> * OBJECT elements whose declare attribute has been set. >> >> >> >> Hidden controls and controls that are not rendered because of style >> sheet >> >> settings may still be successful. >> > >> > I interpret the above to mean that any text input with a value >> > attribute (even `value=""`) is successful control, and should be >> > included in the encoded form data. This is what current versions of >> > Chrome and Firefox do, at least. I have not found any examples of >> > browsers which are known not to do this. >> > >> > What I would like to change in Django is for it to stop assuming that >> > missing POST data for a character field is actually an empty string, >> > and instead raise a form validation error that would prevent the model >> > instance from being saved to the database (potentially causing data >> > loss for that field). >> > >> > I don't see any benefit in the current behaviour, except to >> > potentially support undetermined and unspecified UAs which might treat >> > form fields as unsuccessful controls if the have an empty string as >> > their value, and if those UAs accordingly do not include those fields >> > in the encoded form data. Even if such UAs were found, I would argue >> > that the RFC and HTML4 specs show that text fields with a value (even >> > an empty string) are successful controls that should be included. >> > >> > Failing that, I would like for Django to at least raise a loud warning >> > when a form is bound to data is missing values for character fields, >> > so that it will at least be easier to detect this silent and >> > unexpected data loss in a test environment, before it occurs in a >> > production environment. >> > >> > Does anybody else have opposing or supporting arguments, or any >> > knowledge of actual UAs that do not include fields with empty values >> > in their encoded form data, or an alternative interpretation of the >> > RFC and HTML4 specs above? >> > >> > Cheers. >> > Tai. >> > >> > [1] http://www.rfc-editor.org/rfc/rfc1866.txt >> > [2] http://www.w3.org/TR/html4/interact/forms.html#h-17.2 >> > [3] http://www.w3.org/TR/html4/interact/forms.html#successful-controls >> > >> > -- >> > 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. >> > >> > >> >> -- >> Sent from my mobile device >> >> -- >> 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. > -- 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.
