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

[Shane Hathaway]

Steve Alexander wrote:
> I think a good approach for my typical use-case is to say that the field 
> is required and can contain any string value, including the empty string.
> 
> The widget used to present the field is configured such that if there is 
> no value filled in on the form, the empty string is used.
> 
> The difference is that the widget is responsible for the policy of what 
> a missing value on the form is to be mapped to on the field. Often, 
> we'll want the widget's to map a missing input to the field's 
> missing_value. A common case with text fields is that the widget will 
> map a missing input to the domain value of the empty string.

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.  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. :-)

Shane