Hi there, 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 a subform.
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.
Regards, Martijn _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
