-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.
