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

[Garrett Smith]

Shane Hathaway wrote:=20
>> 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.
>=20
> So widgets internally use some notion of "no input", which they
> translate into:
>=20
> - for non-required fields, a missing value.
>=20
> - for required fields, a validation error.

I think we're into implementation details here, but I would say that the
widget shouldn't know/care about a field's constraints -- the field
should handle its own validation, raising errors based on what the
widget provides. I.e. if a widget supports 'missing', then it should try
to update the field with field.missing_value, regardless of the field
constraints.

> This makes sense.  However, there's this weird case where a text
> widget representing a non-required text field needs to interpret "no
> input" as an empty string value, rather than a missing value.  I
> don't understand why this odd case doesn't seem to occur with other
> widgets, but it's not specific to browsers.

Hmm. I don't follow this -- I'm making the assertion that text widgets
*never* have missing values. But see concessionary language below.

>> - 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'.
>=20
> However, a text widget representing a required text field supports the
> notion of "no input" and will generate a validation error if the
> widget is left empty.

Perhaps my thinking is wrong then -- text widgets do support missing
values. It's probably most natural to think of a required text field as
requiring at least one non-whitespace character -- i.e.
len(value.trim()) > 0. But then wouldn't a text field's missing_value be
'' (empty string)?

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.

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

Perhaps then browser widget *should* support a missing value -- whenever
an empty string is submitted? What's the Right Thing here?

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

>> - 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).
>=20
> 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?
=20
 -- Garrett