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

[Garrett Smith]

Shane Hathaway wrote:
> 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.=20

I think we can cover this case if:

- TextField defined missing_value as '' (empty string), which would
imply/require a constraint of min_length > 0

- TextWidget translated an empty string or missing input (i.e. not in
the form) to field.missing_value

That both stays within the current working definitions of 'missing
value' and 'required' and behaved the way users would expect.

That said, it annoys me that these distinctions are so subtle -- it will
be hard for casual developers to grok the implications setting required
and missing_value.

> 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=3D1" or "min_items=3D1".

I'd hate to see the notion of 'required' dropped, since its so natural.
Perhaps we should just make 'required' something that each field can
define for itself. E.g. drop required from IField and move it into IText
(and other types, if need be). IText could interpret required as
len(value.trim()) > 0...in which case required is just another
constraint, having nothing to do with missing values. Or, if you're
feeling austere, just rely on min_length.

It would follow that missing_value would also be dropped from IField.
Fields that supported this notion could define it how they saw fit.

This line of thinking assumes that there is a tight relationship between
widgets and fields (widgets are, after all, views to fields). Let's not
try to standardize widget/field relationships to such an extent and let
developers add settings/features only as needed.

E.g. when I hear myself argue "boolean values can be missing, i.e. None"
I hear my other self reply, "dude, it's a boolean, uses a checkbox, lets
not get crazy here." So, perhaps required and missing_value have no
place in Bool, and therefore no place in Field. Someone that really
needs to have a Bool that supports None can either define a new field
(and consequently a new widget) or use an enumeration-style field to
capture one of three values.

>> While this might be counterintuitive, I think it's 'logical' (in the
>> Dr Spock sense).
>=20
> Mr. Spock's logic is often wrong because it's too confined. :-)

That's right...*Dr.* Spock was the child-raising guru :-)

 -- Garrett