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

[Steve Alexander]

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

Sounds good to me. Although, I expect that a widget that can choose 
whether to offer a missing value or not will choose according to whether 
the field is required or not... but not in all cases. For example, I 
have a client who likes drop-down boxes for both required and 
non-required fields to look like this:

   [ ---- ][v]


   [ ---- ][v]
   | foo  |
   | bar  |
   | baz  |
   +------+

The important feature of this is that on the first rendering of the 
widget, the initial value does not prejudice whatever value might be chosen.

If the user leaves the '----' value selected, and the field is required, 
then the field will issue a validation error.


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

Different text widgets need to support different missing values, 
depending on the application.

We can probably settle on a "most generally useful" one for the Zope 3 
application. However, I know that I'll need a variety of options for my 
software.


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

<pedant>
Dr Spock was a child behaviourist with some rather disturbing theories.
Some say that his theories are responsible for a generation of screwed 
up children.
</pedant>


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

I agree that this should be true.


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

That makes sense to me. If I ask a non-required field "so, tell me what 
values I can give you without you raising an error" then the 
missing_value should be included in what is returned.

I don't know whether allowed_values is meant to answer this question, 
though.

--
Steve Alexander