[Zope3-dev] Schema, widget and form refactoring (was Re: [Zope3-checkins] CVS:Zope3/src/zope/schema - _bootstrapfields.py:1.19.2.1)

[Garrett Smith]

Jim Fulton wrote:
> I'm hoping that a clarification of the meaning of "required",
> "missing", and "default" might help here.  I'm inclined to think
> though that if a user hasn't provided input, then we shouldn't
> substitute a default or missing value for an existing value.

Absolutely +1

>>  > - Text fields have a missing_value of '' (empty string) instead
>> of None.=20
>>=20
>> Argh.  I know there is a popular position that this is the right
>> thing to do, but it doesn't feel right to me.  Using None as the
>> default missing_value makes it easier to detect careless bugs.
>=20
> I agree. What is the motivation for making '' the default missing
> value?=20

This is Steve's position, so I won't speak for him. I think in practice,
though, users of HTML forms will expect a blank string to be considered
'missing'. I realize that a) we haven't defined 'missing' (doing that as
we speak) and b) fields aren't used exclusively in HTML forms.

I see the merits of both sides here and, ultimately, this is a design
decision for the schema author. This is why I exposed missing_value in
the Field ctor.

> I don't remember what you suggested, but something like:
>=20
>    getInput(()
>=20
> might be better

It would be nice to see a delineation in the API between values that are
meant for objects and internal data used by the widget. Currently, I
have these as getData and getUnconvertedData respectively.

getUnconvertedData -> getUserInput?

Btw, the notion of convert and unconvert is a bit ambiguous. I think
something like:

  fieldValueToUserInput(fieldValue)

  userInputToFieldValue(userValue)

I realize that 'user' input doesn't always come from users, but I think
it's useful to think of this data in terms of what is submitted to the
field or HTML form.

=20
>> haveData() (hasData() in your branch)
>>     Whether or not the field was present in the request that caused
>>     the form to be generated.  For complex widgets,
>=20
> And some very simple widgets, like checkboxes
>=20
>  >     it's almost
>>     impossible to get away without a marker to say "I'm here",
>>     especially if a valid state is to have no other input from the
>>     browser

I think widget's need to support another term: 'unspecified'. This is
different from 'missing'. Missing means that we have data, and it's
'missing_value' (e.g. None, 0, '', etc.). 'unspecified' means that this
widget has no input -- it's a no-op as far as any 'applyUpdates' are
concerned.

In my branch, unspecified is True (for browser widgets) when that
widget's field is not in the form:

  widget.name not in widget.request.form

But it would be nice to see this in the API somewhere.

> This might be a good time to rename this to haveInput.

haveInput??? so we can later rename this to hasInput? ;)

I prefer something like hasUserInput, or isValueSpecified. In my
experience here, I found it important to clearly differentiate 'data'
that is typed into a field (or in a form) from 'data' that from or going
into an object. Thus

  fieldValue and userInputValue

or something else what clearly delineates the two types of 'data'.

>> You're changing the interpretation of haveData() in a fundamental
>> way.  It may work for most of the standard widgets, but I'm very wary
>> of this change.  (But like I said, I've not read the code yet.)
>=20
> Right, I wonder what the motivation for this is.

Because a 'missing value' is a perfectly legal value to submit -- and to
return hasData as False is plain wrong here. The widget has data -- it's
the missing value. It may turn out that 'missing' should fail on the
'required check' but that doesn't mean the widget doesn't have data.
=20
> I think we have enough experience with this framework that we can
> identify some problems.  I think it would be worthwhile discussing
> the issues and possible solutions before we go much further.

I'll get something posted today and try to enumerate the outstanding
issues.

 -- Garrett