Zopache

On Registering Widgets

Registering classes and views is great, but registering widgets is
a bad idea. It is the wrong level of granularity.
If someone else registered a class, I can subclass it, register my
subclass, and then wherever it is used, they get the new version of the
class. Brilliant. If someone registerd a view, then I can also
replace it. Also brilliant. But registering widgets is not such a good
idea. Say I register a new widget for some existing schema field, then
all the views that use that widget are changed. I should not be
globally changing all the views that use a single field, and that others
have written and are responsible for. That is the wrong level of
granularity. Instead, I should explicitly replace just the views I need
to change.

Accordingly, I would love to see the creation of grokcore.widgets and
grokcore.fields without widget dispatch. The fields would choose their
widgets for display and editing. If there were a choice of widgets the
field specification could call for which widget to use. If a developer
did not like the choices, he could subclass that field, or better yet override it in the form.

Furthermore it would be great to get one file per class, with first the
interface, then the code. That way a google search would turn up the
page, and it would be easy to find the needed information. Much easier
for the library users.

I love zope.schema fields. And the rich collection of zope.formlib
widgets is also great. I am not so thrilled about converting from one
to the other. Mostly it happens automatically, but for new situations,
we get into triple dispatch. What the hell is that. Worse yet, it
requires ZCML! I am a simple Man. KISS! In zopache when a ZClass field
is defined, the author can select the widget used to display it. I can
grok that.

I invite you to Register and then link to your own blog postings and
software packages..