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

[Garrett Smith]

Here are some thoughts...not sure if any of this is in contention, but
maybe it will help to identify points of agreement/disagreement.

It seems to me that we have the following very-high-level issues:

- Nature and behavior of widgets in general
- Nature and behavior of browser widgets
- Nature of fields in general
- Nature of Zope 3 core fields (e.g. text, text line, int, etc.)

Starting with fields-in-general, are we still in agreement that Zope 3's
fields support 'missing values'? So far, I think what we have works very
well: a field must define a missing value, but if it is 'required', that
missing value cannot be legally assigned. I.e. the notion of 'missing
value' is not meaningful for required fields.

Next, can we also say that widgets-in-general can *potentially*
represent a 'missing value' -- i.e. represent a value that is considered
'unknown' to the user? Here I think of MS Access, which lets the user
'delete' a boolean value (literally, by pressing the DEL key), resulting
in that value being null. Another example might be a dropdown that is
used to present the user with options:

  Default
  On
  Off

which is used to set a boolean value to None, True, or False.

At the same time, some widgets cannot represent a 'missing value'. E.g.
a simple textbox does not allow the user to say 'I don't know what this
value is' -- the user ends up entering something non-missing every time
the form is submitted/saved/applied. To support a missing value, a text
widget would need some addition UI feature to let the user explicitly
convey the 'missing value' -- e.g. provide an additional checkbox that
enabled/disabled the textbox.

So, it seems to me, each widget must decide if it supports a 'missing
value'. If it does not, any application of that widget's value to a
field will result in a non-missing value.

Here are some assertions:

- The text widget, when rendering as a textbox, *cannot* support a
'missing value' since there's no way for a user to say 'I don't know
what the value is'.

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

- The int widget *can* represent the missing value by a blank textbox.
If a user doesn't know the value, he/she can leave the text field blank.

- Fields should support crazy missing values like an empty string. The
only condition is that the missing value cannot also be a legal value.
E.g. a text field that defines missing_value as '' should also have a
constraint min_length > 0.

- If a widget supports the representation of a missing value and that
state has been selected/specified by the user, the widget should attempt
to update its field with the field's missing_value.

Here are some conclusions from the above:

- A text field that doesn't have allowed_values (i.e. is rendered by a
textbox) cannot be set to field.missing_value (aka None) by way of the
text widget. If a developer wants get None into a text field by way of a
widget, he'll have to create a new widget...one that lets the user
explicitly indicate 'missing'.

- A boolean field cannot be set to field.missing_value by way of the
checkbox widget. If a developer wants to support 3 values for a boolean
field, he'll have to use a customer widget...e.g. a dropdown with
options None, True, and False.

Thoughts?

 -- Garrett


Steve Alexander wrote:
>=20
>> I'd like to understand where this leaves us.
>>=20
>> 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.
>=20
> 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.
>=20
> So, "required" may make sense for a Boolean field, and can be
> represented by some kinds of widgets but not others.
>=20
>=20
>> 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.=20
>>=20
>> 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.
>>=20
>> I don't know whether others agree. :-)
>=20
> I'll need to think about this a lot more before I can say whether I
> agree or disagree :-)