z3c.form在Plone4的应用

文本 z3c.form
文档
相关的几个包
plone.z3cform
plone.autoform

plone.app.z3cform
入门教程
http://plone.org/documentation/kb/using-z3c.form-forms-in-plone/create-a-simple-z3cform
http://plone.org/documentation/kb/using-z3c.form-forms-in-plone/tutorial-all-pages
professional plone4 development 第１１章　Standalone Views and Forms
collective-docs.pdf 266 page
理解：
Although z3c.form is not part of Plone officially, it is used by a
number of add-ons, some of which are liable to become part of Plone in
the future. z3c.form is also a more palatable choice than zope.formlib
for schema-driven forms for a number of people today.

Right now, we use plone.z3cform for the Zope 2 integration. This does a
number of things (listed below), but the main point of this package is
to deal with the need for acquisition and other Zope 2 requirements.

We also have plone.app.z3cform, which provides a Ploneish form template
for forms, and KSS-based inline form validation.

With formlib, Products.Five.formlib took the approach of providing
alternatives for each zope.formlib base class that mixed in Zope2-isms.
plone.z3cform takes a different approach, relying on a Zope2-aware
wrapper view that performs some setup (like monkey patching the request)
and renders part of the page, and then invokes a "vanilla" z3c.form form
class, rendering its output into the page body.

With Zope 2.12, views no longer need to mix in acquisition. This means
that we can get rid of the wrapper view, or at least deprecate it. I
think this would be worthwhile, because the wrapper view indirection
adds overhead and complexity, and makes z3c.form-in-Plone different to
z3c.form elsewhere.

Also, two criticisms have been leveled at z3c.form:

- The templates produce unclean markup with redundant elements. This
is actually down to the Plone templates in plone.app.z3cform, as the
widgets in z3c.form are more or less just <input /> tags, except in a
few edge cases (like the composite object fields, which are weird in any
case and rarely used).

- It is difficult to use with hand written templates. I actually think
this is mostly just a documentation issue, as it's easy to use a custom
template with z3c.form, but we probably want to explore this a bit more.

My thought is to end up with the following:

- The wrapper view (layout.py) will stay and remain the way to use
z3c.form in Plone 3 (and Zope < 2.12).

- In Plone 4, you'll be able to dispense with the wrapper view.

- plone.app.z3cform will install a layer using browserlayer.xml that
extends z3c.form.interfaces.IFormLayer. This means no need to mark the
request with this on-demand in plone.z3cform's z3.switch_on(). All other
request modifications performed in this function are superfluous in Zope
2.12.

- There'll be a (cleaned-up) default view template for standard forms
for this layer. This should be broken up into macros that make it easier
to re-use.

- An override for the wrapper view will ensure that this continues to
work in the same way as before.

- The ++widget++ traverser in plone.z3cform needs an equivalent that
works on z3c.form.interfaces.IForm instead of working on the wrapper view.

- Ditto for the KSS inline validation views.

- We'll add some better documentation to these packages to explain how
to use them, including how to use hand-coded templates.

- We can then potentially adjust plone.app.registry, plone.dexterity,
plone.directives.form and plone.schemaeditor (the places I can find that
actually make assumptions about the form being wrapped in a view) to
dispense with the wrapper.

http://plone.org/documentation/kb/using-z3c.form-forms-in-plone/tutorial-all-pages
成功应用的样例：
collective.dancing
plone.app.discussion