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

Powered by Zopache, Grok, Zope and ZODB

Robots Crawl This