On Fri, 2009-01-09 at 00:59 -0800, Flo Ledermann wrote: > Malcolm, > > As a relatively new Django user but experienced web developer I just > found it counter-intuitive that the Form would set fields that are > nowhere specified or even mentioned in the request. To follow your > line of thought, a validation error should be raised if a required > field is not present, but this is not the case, the missing value is > just replaced silently by a default value. The empty string for me is > just an arbitrary value as would be any other value - it is highly > application dependent if the empty string is a sensible default value > for missing values.
Primarily, that's just historical and it's not particularly harmful, providing you're not intentionally passing around invalid data and expecting it to remain invalid or unchanged. The "cleaning" phase of a Character field at the form field level turns None into the empty string. Maybe not the most pure behaviour, but it's also not particularly horrible for valid usage. It's analogous to how you can specify a datetime and date field in a model by initialising it with a string and it is converted to a Python datetime or date object before being saved to the database. I'd prefer Django didn't do that for purity purposes, but it doesn't really get in the way in a practical sense. > On Jan 9, 2:18 am, Malcolm Tredinnick <[email protected]> > wrote: > > On Thu, 2009-01-08 at 07:08 -0800, Flo Ledermann wrote: > > > No. Don't ask the form class to read your mind. Create a form that knows > > which fields it expects so that errors can be raised correctly and > > validation will occur normally. > > I am not asking the form class to read my mind but to read the > request. It does. And validates the request. It just doesn't use the request to work out what the form should be, since the request is created by the browser/user, which is very error-prone. The form is created by the developer and is much more authoritative on that front. :-) > I just didn't realize that django's Form concept is very > presentation oriented and is really (besides other things) a helper > for rendering forms in the template. I do not want to create a > ModelForm class for all possible subsets of fields I am going to use > in the presentation layer for updating the model (besides that, in a > clearly seperated scenario, I couldn't know in advance which fields > will be used in the presentation). What I want from a server-side form > class is a way of specifying how an incoming *request* is mapped to a > create/update operation on the model, no matter from which form of > presentation this request emerged. Sounds like you really need to write your own class or function to handle this type of "generic model update" situation. Nothing wrong with that. Not too hard to write and, you're right in thinking that it's not really something the Form class is intended to handle. > > To conclude, I believe there are three ways of dealing with missing > fields in the request: > > 1. Raise a validation error For required fields, that is indeed the case. Fields that are permitted to be blank in the model definition, when used in a ModelForm are not required, so "missing" won't be a validation error. > 2. Set the field to a default value or NULL Django's character based fields don't work with NULLs. So they use the empty string in place of NULL. Consistently. That's the only variation. > 3. Ignore the field if not required or an update operation an an > existing instance is performed Ignore doesn't really make sense for something at Django's form level. If it's included in the form (which for ModelForms means everything not in the Meta.exclude attribute or everything in Meta.fields) it will be processed. > In my opinion, items 1) and 3) are most intuitive and equally > consistent, so they should be chooseable by a flag. Option 2) is a bit > arbitrary in my opinion, but this is what django does. These three options aren't mutually exclusive alternatives. (1) and (2) are what happen now. As I mentioned, though, fields specified in the form will always be processed somehow. There is some logic built in to handle form fields that might not always be submitted by the browsers (e.g. unchecked check-boxes), but, basically, if the field is specified in the form -- either directly or by implication in a ModelForm, the code will run it through validation and normalisation, which will invoke the "required / not required" logic as part of that. It sounds like there's just a bit of a mismatch between your expectations and what happens. Hopefully that's all a bit clearer now. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
