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.

grokcore.formlib

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.

megrok.z3cform

I should also mention megrok.z3cform. This builds on z3c.form to make it grokable. Very nice product. No problems whatsoever. I did not even notice it, which is perhaps the highest compliment.

Trees

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

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.

Grok should allow replacement of course grained components, not fine grained components.

Take a look at the z3c.form update method

def updateWidgets(self, prefix=None): self.widgets = zope.component.getMultiAdapter( (self, self.request, self.getContent()), interfaces.IWidgets)

And the cryptic error message that I got:

ComponentLookupError: ((, , ), , u'')

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:

def updateWidgets(self, prefix=None): self.widgets=FieldWidgets(self, self.request, self.getCont\ent()): . . .

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

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

Powered by Zopache, Grok, Zope and ZODB

Robots Crawl This