From z3c.form's subform.txt:
"Final Note: With ``zope.formlib`` and ``zope.app.form`` people usually
wrote complex object widgets to handle objects within forms. We never
considered this a good way of programming, since one looses control over
the layout too easily."
I then looked at the addressbook demo of z3c.formdemo to see how to work
with subforms. I am somewhat intimidated, and I'm afraid others (such as
my clients) will be a lot more intimidated. I would therefore like to
ask the authors to consider a "bad way of programming" - widgets for the
Object field. :)
The advantage of having a widget for the Object field to support
complicated nested form requirements is that your code can be
declarative. The clear disadvantage is that it's very hard to control
the layout. This is why z3c.form argues subforms are always the way to go.
It appears however that z3c.form's subform approach also has a drawback:
the code becomes a lot less declarative. The developer is required to
write their own update() methods that pass control down to the subforms,
various page templates that pass rendering control down to subforms, and
various getContent() methods to get the correct information to modify in
There is a *lot* of code in the address book demo, and a lot of little
bits which interoperate with each other. Granted, the form is
complicated, but it's still a ton of code.
The traditional zope form approach has widgets for the Object field. The
Object field can then refer to its own schema, and the widgets are
clever enough to render their own subform. In combination with the List
field very complicated nested forms can, in theory, be created with
relatively little code.
In practice it doesn't work well, as z3c.form recognizes - it becomes
very hard to control layout.
Wouldn't it be possible to design an Object widget where the layout *is*
easier to control? I'm thinking about a scenario where you can easily
supply your own subform, including template, for each Object field, if
you so desire (there should be a default behavior). I hope that by doing
so, some of the complicated control flow that is now in the address book
can be eliminated.
If the addressbook demo reflects the current best way to go about
creating a complex form, it becomes much harder for me to recommend the
use of z3c.form. I myself need Zope 3's form system to make powerful
nested forms not only possible, but also declarative and succinct.
Zope3-dev mailing list