On 17/06/11 07:00, Tai Lee wrote: > If this behaviour were to change, `required` would become a completely > meaningless argument to BooleanField because no value in the GET or > POST data is normalised to `False` because of the way checkbox values > are submitted in HTML forms.
The suggestion is not to change the behaviour of the 'required' attribute, which has to work the way it does, for reasons you describe. The suggestion is to change the default - so that this field, in contrast to most (every?) other field, has 'required=False' by default. Alternatively, you could define 'required' to be meaningless for check boxes, and therefore ignored, since you cannot *not* return a value in some way, and add another attribute like 'require_true' to get the current behaviour. However, that would only be sensible if BooleanField knows that it is using a check box widget, and other widgets are possible that don't have this limitation e.g. two radio buttons with neither initially selected. So it is difficult to work out what behaviour is correct and consistent here - the most obvious definition of 'required' (to me, anything) is essentially meaningless for check boxes, the most common case, but not for other widgets, yet it is an attribute of the field which is widget agnostic. Luke -- LORENZ'S LAW OF MECHANICAL REPAIR: After your hands become coated with grease, your nose will begin to itch. Luke Plant || http://lukeplant.me.uk/ -- 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.
