plone.autoform builds custom z3c.form forms based on a model (schema)
of what fields to include and what widgets and options should be used for each
field. This model is defined as a zope.schema-based schema, but additional
hints can be supplied to control aspects of form display not normally specified
in a Zope schema.

For dynamic forms, you could of course make schema and
additionalSchemata into properties. For example, plone.dexterity extends the
basic AutoExtensibleForm so that schema is the content type schema and
additionalSchemata is a list of field provider schemas associated with
behaviors.

A field can be omitted entirely from all forms, or from some forms,
using the omitted and no_omit diretives. In this example,
the dummy field is omitted from all forms, and the edit_only
field is omitted from all forms except those that provide the
IEditForm interface:

A field’s position in the form can be influenced using the order_before
and order_after directives. In this example, the not_last field
is placed before the summary field even though it is defined afterward:

The value passed to the directive may be either ‘*’ (indicating before or after
all fields) or the name of another field. Use '.fieldname' to refer to field
in the current schema (or a base schema). Use a fully prefixed name (e.g.
'my.package.ISomeSchema') to refer to a field in another schema. Use an
unprefixed name to refer to a field in the default schema for the form.

In supermodel XML, the directives are called form:before and form:after.
For example:

Usually, z3c.form picks a widget based on the type of your field.
You can change the widget using the widget directive if you want
users to enter or view data in a different format. For example,
here we change the widget for the human field to use yes/no
radio buttons instead of a checkbox:

Note: In order to be included in the XML representation of a schema,
widget parameters must be handled by a WidgetExportImportHandler utility.
There is a default one which handles the attributes defined in
z3c.form.browser.interfaces.IHTMLFormElement.

By default, fields are included in the form regardless of the user’s
permissions. Fields can be protected using the read_permission
and write_permission directives. The read permission is checked when
the field is in display mode, and the write permission is checked when
the field is in input mode. The permission should be given with its
Zope 3-style name (i.e. cmf.ManagePortal rather than ‘Manage portal’).

In this example, the secret field is protected by the
cmf.ManagePortal permission as both a read and write permission.
This means that in both display and input modes, the field will
only be included in the form for users who have that permission:

Sometimes rather than rendering a form for data entry, you want to display
stored values based on the same schema. This can be done using a “display form.”
The display form renders each field’s widget in “display mode,” which means
that it shows the field value in read-only form rather than as a form input.

To use the display form, create a view that extends WidgetsView like this:

To render the form, do not override __call__(). Instead, either implement
the render() method, set an index attribute to a page template or
other callable, or use the template attribute of the <browser:page />
ZCML directive when registering the view.

In the template, you can use the following variables:

view/w is a dictionary of all widgets, including those from non-default
fieldsets (by contrast, the widgets variable contains only those
widgets in the default fieldset). The keys are the field names, and the
values are widget instances. To render a widget (in display mode), you can
do tal:replace="structure view/w/myfield/render" />.

view/fieldsets is a dictionary of all fieldsets (not including the
default fieldset, i.e. those widgets not placed into a fieldset). They keys
are the fieldset names, and the values are the fieldset form instances,
which in turn have variables like widgets given a list of all widgets.

Zope schema fields do not allow storing arbitrary key-value data associated
with a particular field. However, arbitrary data can be stored in a
dictionary on the schema (interface) known as the “tagged values.”
This is where plone.autoform keeps track of its extra hints,
whether they are configured via Python directives, an XML model, or some
other way.

The tagged values are stored under various keys, which are defined
in the plone.autoform.interfaces module. They can be set several ways:

Manually, by using setTaggedValue() on an interface.

By loading the schema from a plone.supermodel XML file and using the
form: prefix

By using the directives from plone.autoform.directives while defining
a schema in Python.