Move Archetypes into CMF

Chris McDonough resurfaced a long-standing suggestion that the Archetypes framework move "down" into the main CMF distribution. Discussion of this notion accounted for a large majority of the list traffic this week.

Some of the issues raised were:

• Archetypes is big, enough to make for a weigty testing / integration / documentation burden.

• Archetypes competes with Zope3 schemas. In general, the sense was that Zope3 is still a ways out, and that the Archetypes folks are already planning to move the product toward easy (maybe even seamles) migration to Zope3.

• Archetypes competes with the CPSSchemas product; those who know the two products better than I note that Archetypes tends to produce "static" schema definitions (per class), while CPSSchemas are more "dynamic" (bound to portal_type). One fortunate outcome of the discussion has been that the two teams can begin to see ways in which their overlapping products might merge!

• Archetypes is currently licensed undre the GPL, and must be relicensed to the ZPL before importing it into cvs.zope.org. The authors have expressed willingness to relicense in the past, so this should not be a blocker.

• Archetypes depends on Plone's CMFFormController tool. Opinions differed wildly on whether to migrate that tool down. I don't know enough about it to judge, yet.

• Archetypes also depends on Plone's PortalTransforms tool; consensus seemed much broader for moving it into CMF (for instance, CPS uses it as well). Likewise the UID generator tool and the references machinery. I need to look at all of these more closely: for one thing, we likely have parallel implementations in client software, and I would prefer to be consolidating.

Migrate the portal_setup tool out to CMF

There are a number of efforts to ease the process of exporting "through-the-web" site configuration (tool settings, for instance); such an export would make putting those policy choices under version control easier, as well as easing the process of migrating them between sites.

Alternate solutions include:

• DCWorkflowDump

• ZSyncer

Land CMFActionIcons

As with the portal_setup tool, the portal_actionicons tool is a result of my long-term project with Boston.com. In this case, the code is already over the wall, added to the public CVS repository in preparation for last spring's OSCOM sprint:

http://cvs.zope.org/Products/CMFActionIcons/

At the request of the Plone team, I released CMFActionItems-0.9 in October.

http://zope.org/Members/tseaver/CMFActionIcons/CMFActionIcons-0.9

Add Epoz-friendly editing skins

Epoz is a Zope add-on for exploiting the "in-place" editing facility of recent IE and Mozilla. Allowing content owners to edit their content with WYSIAG tools seems a worthwhile goal (structured text is less than popular with non-technical CMs).

Alex Limi pointed out that there are two versions of Epoz, and that the older (but more stable) version was hard to extend; I replied that I wasn't planning to do anything complicated with it.

Make "classic" DCWorkflow the default workflow

Yuppie has already checked this in. "Death to DefaultWorkflow!"

Add OrderSupport to PortalFolder

OrderSupport was added to the OFS package for Zope 2.7, defining a mix-in class, OrderSupport, used to declare containers which allow specifying the order of their items explicitly. The proposal is to extend CMFCore.PortalFolder (and therefore, CMFDefault.SkinnedFolder) to include this support.

Which brings up the "meta" question: which version(s) of Zope will CMF 1.5 support / require? If we require 2.7, then this is a trivial exercise (skinning what is already wired into the underlying Folder class). If not, then we need to backport OrderSupport, at least for older Zopes.

Support for Enforcing Vocabularies

The portal_metadata tool allows the site manager to express a constraint on a metadata field's value by defining a "vocabulary", a set of allowed values. Because when and how to enforce such restrictions is a policy decision (in some cases, the policy mighter only be enforced at particular times, e.g. at workflow transitions), the "stock" CMFDefault skins don't actually ever check the constraint.

The proposal here is to change that default, so that the metadata editing form always enforces the constraint, and to fix an underlying bug in the tool:

http://zope.org/Collectors/CMF/217