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

[Steve Alexander]

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

I can imagine an application that is created to replace some existing 
paper-based process. On the paper-based process, people are told that 
all boxes must be filled in with something, but they must write "N/A" in 
any boxes that do not apply. (I've seen this on many bureaucratic papers.)
This could be handled by a text-widget that detects text that looks like 
"N/A" and uses the field's missing_value in that case.


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

See above.


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

I have the requirement to make the "dunno" say something else, often 
internationalized and depending on the Field. (At least, I think it 
depends on the field. Does that sound odd?)


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

Yes. Or fill it with "N/A", if you write the widget that way.


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

Why should I need to constrain the field like this?
Can't a field say that its valid values are the set of all values, 
except its missing value, constrained by the field's constraints.
That is, missing_value is a constraint in itself.


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

Yes.


--
Steve Alexander