Supermodel vs. Userschema

In fact, plone.supermodel was originally based on userschema. However, as the
package was refined and refactored, less and less of userschema remained,
to the point where we’d have needed to significantly refactor the latter to
keep using it.

The XML import/export code is currently based on algorithms that were written
for plone.app.portlets and plone.app.contentrules’ GenericSetup handlers.

Some of the key differences between the two packages are:

userschema can create schema interfaces from HTML forms and CSV
spreadsheets. plone.supermodel does not support such configuration.

Schemata created with userschema are typically loaded at startup, with
a ZCML directive. plone.supermodel supports a “pseudo-base class” syntax,
as seen above, to define interfaces in Python code. Beyond that, its API
is more geared towards runtime configuration.

plone.supermodel supports serialisation of schemata to XML.

The plone.supermodel XML syntax is more directly tied to zope.schema
fields, and infers most parameters from the schema interface declared by
each zope.schema field. This has two advantages:

API documentation for zope.schema can be easily applied to <schema />
blocks

New fields and obscure attributes are easier to support

plone.supermodel’s XML schema is intended to support more schema metadata,
including widget hints.

In the future, it may be possible to make userschema re-use part of
plone.supermodel or vice-a-versa, with more refactoring.

1.2.0 (2012-10-17)

1.1.2 (2012-08-29)

1.1.1 (2012-04-15)

Fix a packaging error.
[esteele]

1.1 (2012-04-15)

Support i18n:domain and i18n:translate for internationalization.
[davisagli]

When an error is encountered while parsing a supermodel, the exception
now provides the filename, line number, and source of the part of the
model that was being processed. Inclusion of the line number and source
requires lxml.
[davisagli]

1.0b6 - 2011-01-04

1.0b5 - 2010-04-19

Added support for zope.schema.Decimal fields.
[optilude]

1.0b4 - 2009-11-17

Ignored vocabularyName property when writing Choice fields. The constructor
still uses they ‘vocabulary’ key in an overloaded capacity. We only support
‘vocabulary’ with a named vocabulary, or ‘values’ with a list of values.
This fixes test failures on Zope 2.12 / zope.schema 3.5.4.
[optilude]

1.0b3 - 2009-09-28

Add support for synchronising marker interfaces found on source fields
to syncSchema().
[optilude]

1.0b2 - 2009-07-12

Changed API methods and arguments to mixedCase to be more consistent with
the rest of Zope. This is a non-backwards-compatible change. Our profuse
apologies, but it’s now or never. :-/