[Zope3-dev] Re: [Zope3-checkins] CVS: Zope3/src/zope/schema -_bootstrapfields.py:1.19.2.1

[Shane Hathaway]

Garrett Smith wrote:
> Shane Hathaway wrote:
> 
>>Here's the core of the problem: there is already a shared
>>understanding of the word "required" that doesn't fit your
>>definition.  When you fill out a form on many web sites, some of the
>>text fields are marked with an asterisk.  Some explanatory text says
>>"Fields marked with an asterisk are required".  It would be more
>>precise for them to say such fields "require non-empty input", but
>>that's more verbose than necessary.  The same word is used on paper
>>forms as well. 
> 
> 
> I think we can cover this case if:
> 
> - TextField defined missing_value as '' (empty string), which would
> imply/require a constraint of min_length > 0
> 
> - TextWidget translated an empty string or missing input (i.e. not in
> the form) to field.missing_value
> 
> That both stays within the current working definitions of 'missing
> value' and 'required' and behaved the way users would expect.
> 
> That said, it annoys me that these distinctions are so subtle -- it will
> be hard for casual developers to grok the implications setting required
> and missing_value.

That seems excessively subtle.  Can't we just make the text widget act 
differently for required text fields than for non-required text fields?

>>An acceptable alternative would be to drop the word from schemas
>>altogether.  To express that some input is required, schema authors
>>would say some something like "min_length=1" or "min_items=1".
> 
> 
> I'd hate to see the notion of 'required' dropped, since its so natural.
> Perhaps we should just make 'required' something that each field can
> define for itself. E.g. drop required from IField and move it into IText
> (and other types, if need be). IText could interpret required as
> len(value.trim()) > 0...in which case required is just another
> constraint, having nothing to do with missing values. Or, if you're
> feeling austere, just rely on min_length.

I prefer to keep the required and missing_value concept for all fields. 
They jive with the imprecise but close-enough way we think.

> E.g. when I hear myself argue "boolean values can be missing, i.e. None"
> I hear my other self reply, "dude, it's a boolean, uses a checkbox, lets
> not get crazy here." So, perhaps required and missing_value have no
> place in Bool, and therefore no place in Field. Someone that really
> needs to have a Bool that supports None can either define a new field
> (and consequently a new widget) or use an enumeration-style field to
> capture one of three values.

Not all forms will be automatically built from schemas.  Someone could 
build a custom form that's compatible with a schema and uses a drop-down 
for a boolean field.  Or someone could decide to map required boolean 
fields to a drop-down in context of a particular form or application. 
That means required and missing_value could be useful for even a boolean 
field.

Shane