Zope 3, Formlib, and the Role of Archetypes

Archetypes has been enormously beneficial to Plone developers’ productivity, and in this chapter, we have aimed to show its most modern side. At the same time, some aspects of its design are showing their age. For example, it would be nice if Archetypes schemata did not overlap with interfaces using fields from zope.schema. Some developers also frown at the Class Generator, and the use of separate accessor and mutator methods for each field. Perhaps more importantly, it would be very useful to be able to support proper add forms, and avoid premature object creation.

All of this is of course part of the same type of evolution that Plone, CMF, and Zope are experiencing in light of Zope 3. Given the incredible prevalence of Archetypes in modern Plone development (not at least as the framework underpinning all the core content types), there are absolutely no plans to abandon it. However, in the future, more of Archetypes’ internals may be built upon a more general architecture shared with Zope 3 and other aspects of Plone. For example, there is ongoing work to separate out functionality such as the reference and transformation engines into generic components not tied to Archetypes and its notion of a schema.