Zopache

z3c.form is a zope library to create complex forms. It is natural in python to break domain models into lots of small objects. But people like to look at a single page at a time, so z3c.form does CRUD on single web pages backed by graphs of objects. Most needed.

Z3c.form is a brilliant piece of software. It understands that I have a fine grained object model, but that the user wants to see a web page, or a web form that accesses multiple fine grained objects, so it allows me to create groups of fields, even trees of groups of fields, where each group element can be operating on a different context, and display, update and generate error messages on those contexts.

But sadly all is not well with z3c.form. The ZCA messes up this fine piece of software. z3c.form requires registration of widgets and widget templates. Registering widgets is difficult for the beginner to understand, registering templates is impossible. Now that I am more experienced, I think I could figure out how to register widgets, but I still think that registering templates is impossible.

Worse yet registering widgets and templates makes no sense to me.
There I said it. The emporer has no clothes. Sure registering views on objects makes a huge deal of sense. It just intuitively works. And looking up views based on parent interfaces all works and makes sense, but for widgets????

Just think about it for a minute. There should be a default behavior. Every field should have a default widget. And every widget should have default input, display and hidden renderings. If you need a different field for a particular field/widget, then just specify it in the form. The idea that I can register a new widget, that impacts ll the forms in the system, just does not make sense for large libraries contributed by many developers. The responsibility and granularity should be at the level of the form, not the widget. Chaanging a widget in an existing form could mess up the layout of the form. Better to do it in a subclass, much more intuitive for any oo developer.

Let alone the documentation comments that fields are not registered for IBrowserLayer. What the hell is an IBrowserLayer??? Sure I I can read the code and figure out how to fix this problem, but why bother. Much simpler to just subclass:

The point is that the original version scares off newbies. It sure wasted my time trying to understand it. The latter approach fits the brain of the average python developer. Sure it is fine to do the detailed component stuff internally, but in the code, include a comment with the simpler version for people who want to subclass.

The situation with registering templates for widgets is even more absurd. It requires lookup based on six parameters, let us see if I can remember them, context, request, field, values, widget, and something else. Maybe in giant projects this is needed. But every new Grok developers starts off with a small project, that only gets big when successful. Making an easy entrance for Newbies would do wonders to invigorate this community.