On Fri, 2010-05-28 at 07:25 +0800, Tim Hoffman wrote: > >From the point of view of the form definition, I think you need to be > able to define some type > of sentinal value that indicates a field is empty, but valid if it is > not required. > > I think it would be a mistake to assume that default implies either > required or optional. > It is quite feasible to have requirements where a default value is > provided for a form field > but that no value is ultimately required. And its very common to have > required fields > with no obvious default value. > > So I would personally argue that having default value, and that a > field is required or not be independent of each other.
I agree with how Tim just characterized this. I'm still trying to figure out what the best way to spell it. My current idea is to: - Define a special "null" sentinel value. - Change the type definitions and widget definitions to do something sensible when they see a "null" during serialization and deserialization. (e.g. "n = SchemaNode(default=null)"). - Add a required= flag to SchemaNode, e.g. field = SchenaNode(Integer(), required=True). - Decouple the meaning of default and required. However, that leaves this corner case, which I'm having a difficult time trying to reconcile: n = SchemaNode(Integer(), default=1, required=True) I *think* this means that the "first rendering of the form will display a 1 in the field, but that an empty value will not be tolerated in any resubmission thereafter". However, I'm not sure if that definition matches any sensible use of Colander outside its use as a schema system for Deform, and it needs to, so I'm still chewing on it. - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
