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

[Fred L. Drake, Jr.]

Garrett Smith writes:
 > 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.

General Python practice is to use None for missing values.  It's not
clear that there's a meaningful special case here.

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

The current API never exposes unconverted data; let's avoid changing
that.  All the convert/unconvert stuff in internal, provided for
"convenient" subclassing.

I'll note that our complex widgets don't use that base class.  Too
much baggage.

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

I hope you're able to clarify this distinction.

 > 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

That's not an acceptable test for complex widgets.  I think any
interpretation of request data *must* go through the widget.

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

Whatever.  ;-)  I'll take either as an improvement on haveData().

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

Since the widget API only deals with "converted" data and not the HTML
form fields, there isn't a problem here.

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

If there's a distinguished value for the domain that indicates
"missing" distinct from other values, that's up to the type-specific
conversions.  That's distinct from the widget-level concept of a value
that's missing.

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

Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation