[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:
 > But you're not disputing the need for missing_value. You just want text
 > default to be None instead of <empty string>, correct?

That's right.  I'm happy to see missing_value implemented, though I
currently doubt I'll use it much myself.  It's fairly reasonable, and
maybe necessary.  Very smart people have claimed a need support None
as a valid domain value, and that's good enough for me.

 > The convert/unconvert is different from 'what the user typed into the
 > box' data.

This isn't made terribly clear from the documentation on the trunk.

 >            This should be public and in the API, IMO.

Who beyond the widget needs it?  If it's only needed for subclasses,
it doesn't need to be in the interface.

 > In fact, I'd argue that all of this conversion stuff should be handled
 > *outside* the widget -- and that the widget focusses only on UI issues.
 > These have become exceedingly intelligent widgets -- bad, IMO.

I disagree.  What sorts of conversions need to be done depends on the
sorts of user inputs are available; not all possible inputs will be a
string, a list of strings, a dict filled with strings, or None.
Whatever deals with the input source has to deal with converting that
to something useful.

That's what a widget does.

If you want to remove something from widgets, make it the label() and
row() methods.  And the things Jim's marked as deprecated (render(),
hidden()).

 > But I'm certainly not signing up for changing this now :-)

Thank you.  We seem to have enough going on at once.  ;-)

 > This distinction arises in the fact that *all* of the widgets are
 > populated in preparation for the form submit processing, even those
 > widgets that don't have data in the form.

I'll think about this some more.  It's good that you're questioning
the assumptions, but it's not clear to me that this particular aspect
is getting anywhere.

 > Okay...I see this. I think we need to create one of these complex
 > widgets asap and plug it into an ftest. It's going to pose problems, for
 > my branch, or the head.

They tend to be less than trivial to create.  I'll see what I can do
about getting something released that can be used to create tests.  We
have a widget for a VocabularyUniqueListField that supports control
over the order of the list and which has been tested with multiple
query helpers.  Complex enough?  ;-)

 > These complex widgets are troubling -- there's a lot of assumptions that
 > widget 'user input' comes via a single form value. These assumptions are
 > not only in my branch.

Where are these assumptions made?  The only place I've noticed is in
the zope.app.browser.form package, which is really just a pile of
widget implementations.  We've certainly created and very successfully
used widgets that defy that assumption.  The general form-handling
code in zope.app.form seems fine; it goes to the widget to find out
what's what.


  -Fred

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