[Zope3-dev] Changes to browser widget framework

[Garrett Smith]

I've updated

   http://dev.zope.org/Zope3/CleanupOfSchemaAndWidgets

with some details regarding the proposed changes to the browser widget 
framework. I've included the applicable text below.

If you've created custom widgets, this definitely concerns you. The bad 
news is that the changes break backward compatibility. The good news is 
that it's an easy migration and your code will be cleaner (hopefully :).

I have these changes implemented in my sandbox with tests passing. I 
won't commit anything until we're all comfortable with the proposal -- 
anything below is subject to revision, so please comment.

  -- Garrett



Cleanup Widget Implementation Framework
----------------------------------------

Currently, all browser widgets extend zope.app.form.BrowserWidget.
However, BrowserWidget assumes a particular implementation that is
for simple widgets that are rendered using single tags like 'input'
and 'select'. BrowserWidget is not well suited for complex widgets
like those used for vocabularies.

Create an InputWidget Mixin

   This would be a simple mixin that would provide any functionality
   that could be implemented across all of the widgets, at least by
   default.

Changes to BrowserWidget

   This class should become a simple mixin for browser widgets. It
   should not assume any particular implementation in terms of
   form/widget relationships.

Create zope.app.form.browser.SimpleInputWidget

   This new class would take on most of the functionality currently
   handled by BrowserWidget. The choice of "SimpleInputWidget" reflects
   the fact that the browser is a) an input widget and b) simple. I
   prefer it to leave out the term "browser" in the name for brevity.

   Along with the class rename, I propose the following changes:

   - Rename _convert to _toFieldValue

   - Rename _unconvert to _toFormValue

   - Rename _showData to _getFormValue

   - Remove deprecation warnings

Change Several Widgets' Base Class from BrowserWidget to SimpleInputWidget

   All of the widgets in textwidgets.py, boolwidgets.py, and
   itemswigets.py should be derrived from SimpleInputWidget.

   Widgets that aggregate other widgets or otherwise use multiple
   HTML form elements (e.g. sequence widgets and object widgets)
   should continue to subclass BrowserWidget. They may use the
   InputWidget mixin described above.

Decouple Widget.required from Field.required

   Currently a widget's required value is always equal to its field's
   required value. I believe this is wrong. The widget's required
   attribute should indicate how the widget is displayed in the UI, not
   whether or not the value is required. In fact, the widget validation
   correctly uses the field's required value, not the widget's required
   value.

   The widget's required value should default to the field's, but it
   should be possible to change the widget's value in order to change
   the way the widget is displayed.

   This requirement comes up for widgets that *always* provide a
   value such as the checkbox. In the case of the checkbox, it makes
   no sense to indicate that it's "required" in a form &emdash; it's
   impossible for a user *not* to enter a value.

   The requirement also applies to the text widget. In some cases, a
   text widget may be similar to a checkbox in that it's *impossible*
   for a user *not* to enter a value. This may occur when an empty
   string is not considered a 'missing value' and would therefore
   satisfy a 'required=True' constraint. In such a case, we would not
   want to indicate that the widget input is required, even though
   the field input is required.