Forms

On this branch of the tree, I discuss the different options for form libraries and widgets. zioe,formlib does hte basics. Z3c.form is brilliant. It needs megrok.z3c.form. And of course all of them suffer from the problem that widgets are dispatched. Thankfully that is quite easy to fix.

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.

For backward compatibility reasons grokcore.formlib both uses
zope.formlib, and is designed around the structure of zope.formlib.
That gives the new user two different software models fo formlib. I
still have not figured them out. All I know is that I am not allowed to
subclass the render method. Very frustrating. Best if there were just one grok formlib library. Much less confusing.

Well first of all trees are hugely important.
Have you ever tried to use a website and choose
from a list of hundreds of countries.
The first thing that they teach you in human factors is never
have more than 7 items in a list, trees and
hierarchies make it so much easier for users.
Sadly trees are hugely missing in the Grok/Zope World.

The challenge is
to find the library that does what I need, and
nothing more. The first package I chose, TreeView just
turned HTML lists into trees. That was easy. But it turns
out I need ot be able to handle large lists. 1000+ Nodes.
And the person needs to be able to search the lists.
Only fancy tree does that.

So how should you choose a tree package? Go to FrancyTree,
and see all the features it has. Figure out the
features that you need, then find a package that has only
those features.

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.

zope.formlib is the basic package for creating forms. It is nice ans simple. ${view.href('http://zopache.com','Zopach.com')} uses it
internally. It supports a flat list of fields, which turn into widgets. While it does support prefixes to the field names, if you need a tree of fields, then you should be using Z3c.form

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