On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee <real.hu...@mrmachine.net> wrote:
> Donald, > > Thanks for sharing your feedback with everyone. > > I do believe that there should be some kind of validation error or at > least a loud warning to the console or logs when a form is bound to > incomplete data. The only time when this should occur is for > "unsuccessful controls" such as unchecked radio buttons and > checkboxes. These shouldn't be a problem for Django, which already > normalises no value for a checkbox to False and any value for it to > True. > > I'm not sure that there is a widespread practice of submitting partial > forms with JS and still expecting the entire form to validate and save > is widespread, or even valid according to the RFC and HTML4 specs > which expect every successful control to be included in the form data. > You are using the word 'form' in two different contexts here -- There is the HTML <form>, on the web page that a user can interact with -- this is simply a (mostly) formalized way for a user to submit data to a web service. (I say 'mostly' because, as we are discovering, there are edge cases where the handling of missing data is not completely specified.) Secondly, there is the Form object that exists with a Django application. This is the only form that we have complete control over, and it is the only place that we get to say that data is or is not 'valid'. There is definitely not a one-to-one correspondence between these two forms, and on the web, we can't assume that we have complete control over both of them. On the one hand, the HTML form is not the only way for a GET or POST request to be submitted. We need to consider, at least: - Modern, mainstream, buggy web browsers, like Chrome or Firefox - Older, mainstream, buggy web browsers - Non-mainstream web browsers - Other HTML-based User-Agents - Other REST-based applications - JavaScript submitting AJAX requests with data serialized from an object (not a form.submit() call), from any number of frameworks - curl / wget command-line interfaces - Python urllib / httplib requests (and other languages' equivalents) - URL query parameters Many of these would never even see or parse an HTML <form> element, but they can all still provide data which will be used to construct a Django Form. We absolutely cannot claim to have the same level of confidence in the behaviour of these that we do by a reading of the RFC and an examination of the output from recent versions of Firefox and Chrome. And then, on the other side, data that comes into a view may be handled by multiple Form objects -- it's not uncommon to render fields in an HTML form that are going to be handled (or not) by several Django Forms. Even in the simplest case -- one HTML form, in a browser window, and one Django Form in a view -- it may even be the case that several fields were left off of the HTML form deliberately, because the same Django view and Form are also used by different pages on the site. In this case, I *want* to declare the fields to be optional, and then choose how to handle it after determining that the presented form fields are valid. With this proposal, I won't be able to, without subclassing the form or providing different views to handle each subset of data that I need to be able to accept. > Sure, I can see that forms could be fully or even partially submitted > via JS to perform AJAX validation in real time, but I don't see how > the form as a whole being invalid and validation errors on the missing > fields would impact that. > The problem is that AJAX (or any number of other methods) could be assembling data that should validate (ie, not for ajax validation, but with the intention of actually submitting data), and it may not be easy (or possible) to match the handling of null / blank / undefined values to what a browser would do. Not having the ability to get past a Django-mandated ValidationError would certainly impact the user experience in this case ;) -- Regards, Ian Clelland <clell...@gmail.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.
