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

[Shane Hathaway]

Garrett Smith wrote:
> The way I'm currently thinking is that 'required' for text fields +
> browser text widget is bascially meaningless since the widget can't
> product a true missing value (i.e. None). Instead, developers that want
> to insist that a text field contain len(string) > 0 should set
> max_length.

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.

We could just keep the mismatched definition, but then programmers and 
managers would understand the word differently.  (Actually, we have that 
problem already--in real life, a form does not have "widgets", it has 
"fields".  Such is life. ;-) )

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".

> While this might be counterintuitive, I think it's 'logical' (in the Dr
> Spock sense).

Mr. Spock's logic is often wrong because it's too confined. :-)

> In any event, this call can be made by the widget at any point without
> disturbing the rest of the framework. (90% confidence ;-)

Yes, this is specific to the text widget.

>>>- The text widget, when rendering as a dropdown (because it has a
>>>list of allowed values), *can* support a missing value by adding an
>>>additional option that lets the user say 'dunno'. Currently, this
>>>option is rendered as a blank entry in the list (not very clear, but
>>>still available).
>>
>>YAGNI. ;-)
> 
> 
> I'm not sure about YAGNI here -- it's the way things work currently. If
> a field is not required, one could argue that missing_value is an
> implied member of allowed_values.
> 
> Do you think we should pull this?

Oops, I misread.  I thought you were talking about rendering a single 
field with two browser widgets.  No, this should stay.

Shane