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

[Fred L. Drake, Jr.]

Garrett Smith writes:
 > In all cases currently:
 > 
 >   widget.request.form.get(widget.name, None)
 > 
 > This would be done during the setup phase.

How does a widget determine what gets provided for this?  For the
complex vocabulary widgets we've done, this isn't even close to
sufficient.  As many as half a dozen different names are needed;
widget.name is just the base; others are formed using widget.name as
prefix.

[regarding getUserInput() / setUserInput()]
 > The name is confusing, given the nature of widgets. It's the
 > read-accessor to 'userInput' -- it returns the value provided by
 > setUserInput.
 > 
 > Perhaps a better way to handle this would be through properties.

Properties would be nice for this, but that's basically sugar.

I don't think "user input" (meaning raw HTML form data) has any place
at all in the IWidget or even IBrowserWidget interface.

 > Ah, excellent. I would still be inclined to spell 'the value meant for
 > the field" as:
 > 
 >   getFieldValue/setFieldValue

I don't see a need for this.  My own preference would be getValue() to
retrieve the value after taking into account the setData() /
haveData() values (or whatever those are renamed to).

 > I think _conver and _unconvert should be made public and renamed to:
 > 
 >   fieldValueToUserInput(value)
 > 
 >   userInputToFieldValue(value)
 > 
 > to clarify what's going on.

Steve Alexander writes:
 > How about importToField and exportFromField ?

The name of these functions and their public-ness are separate
issues.  I don't care what they're called.

These are currently convenience methods implemented on a base class,
and I don't see any reason for that to change.  Better documentation
would be good.  But anything that deals with unconverted data as
either input or output should not be part of the IBrowserWidget
interface.


  -Fred

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