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

[Steve Alexander]

> I'd like to understand where this leaves us.
> 
> The idea of a field being required is good in theory, but certain UI 
> constraints change the meaning of 'required' in a form (both in a 
> browser and in a GUI.)  For example, it's impossible to apply 'required' 
> to a checkbox--checkboxes have only two states.

An MFC checkbox can have three states. For example, it can start out 
grey indicating "neither checked nor unchecked". A required checkbox 
must be moved out of that initial state in order to proceed.

So, "required" may make sense for a Boolean field, and can be 
represented by some kinds of widgets but not others.


> Similarly, text widgets 
> have no intrinsic way to apply 'required', though there is a cultural 
> definition: required means the field needs to have at least one 
> character.  If a text field is not required, that cultural definition is 
> not present, and an empty or missing widget value should translate to an 
> empty string.
> 
> So, I think my typical use case is to say that a text field is not 
> required and thus always contains a string value, including an empty 
> string, and should never take on a missing value.
> 
> I don't know whether others agree. :-)

I'll need to think about this a lot more before I can say whether I 
agree or disagree :-)

--
Steve Alexander