Dexterity ...
- Is a content-type development system for Plone;
- Allows you to develop through-the-web or in Python packages;
- Is light-weight, fast and flexibile;
- Works well with Archetypes content;
- Will eventually replace Archetypes as the basis for Plone's stock content types; and
- Is built into Plone 4.3!
You should be using Dexterity for most Plone content-type development for Plone 4.2+. The only significant exception is for translatable content using LinguaPlone, which does not support Dexterity. A successor to LinguaPlone is in the works, and will support Dexterity.
Want more? I'll be teaching a class on Developing with Dexterity, June 3-4 at Plone Symposium Midwest.
What's New
Plone 4.3 is shipping with Dexterity 2.0.x. There have been a few changes from the 1.0.x series, but nothing that will pose a significant migration problem. See the 4.3 section of the Plone Upgrade Guide for the important details. I'll also discuss some of them below.
Documentation
When Dexterity was an option, its main documentation was in the documentation section of its add-on package in the Plone software center. Now, you may find the Dexterity Developers' Manual on developer.plone.org.
This is exactly the same documentation that you'll find in the "docs" directory of the plone.app.dexterity package. So, it's maintained as part of Dexterity, and automatically included in developer.plone.org through Sphinx and readthedocs facilities. Thanks to Mikko and his documentation team for making this happen! There is, by the way, a new reference section documenting Dexterity's XML name spaces.
Grok
Grok is a set of agile-development tools and conventions that makes it possible to do many things through Python alone that would ordinarily require ZCML wiring. Grok was a dependency of Dexterity 1.0, but the Plone Framework team decided that they did not want it to become a dependency of Plone. Much of what's new in Dexterity 2.0 is about removing Dexterity's dependence on Grok.
The changes make it possible to develop Dexterity packages (this does not apply to through-the-web development) in two different ways: using Grok conventions and tools or by wiring adapters and views through ZCML.
Dexterity's developers still favor Grok. While I think the Framework Team was right to avoid the Grok dependency, Grok makes Dexterity development faster and easier to teach and learn.
To adapt a Dexterity 1.0.x package to 2.0.x, you only need to make one change in your package, to the install_requires section of your setup.py file, to specify the grok extra:
install_requires=[
...,
'plone.app.dexterity [grok]',
...,
If you're creating a package, the Dexterity Developer Manual instructions tell you the couple of additional things you need to do to set up Grok, and the zopeskel.dexterity skeleton includes everything you need.
Grok static resources
Grok has done some changing itself. It no longer automatically maps package directories named "static" into being Zope/Plone resource directories for CSS, js and image files. You may turn that back on, though with a single directive in your configure.zcml file:
<browser:resourceDirectory
name="namespace.package"
directory="static" />
where "namespace.package" is replaced by the dotted name of your package. With that done, you may use http://the_page_url/++resource++product.dotted.name/test.js style URLs to reference files in the static directory.
Relations and RelationFields
If you've been using RelationFields in Dexterity 1.0.x, you should read the "Relation support no longer included by default" section of the Dexterity 2.0 release notes. That will give you a good introduction to the 2.0 changes and allow you to make a decision whether or not you want to use RelationFields going forwards.
Items and Containers
When creating a new content type in Dexterity 1.0.x — whether in a package or TTW — the first decision you had to make was whether the content type would be for an Item (not folderish) or a Container (folderish). Going forward, Dexterity is favoring a style where everything is derived from the container type, but you just decide whether or not it can have contents. This is nice for a couple of reasons:
- Usability testing was showing that new users didn't understand the issues at the point of creating a new type; and
- Deriving from Item left you stuck with a content type that couldn't become a container. Derive from Container, and you may change your mind later.
Dexterity's Item class still works, so old code needs no updates.
ZopeSkel
zopeskel.dexterity has been updated to handle the minor code differences. Make sure you use zopeskel.dexterity 1.5.0 or greater for use with Plone 4.3.
Thanks
Dexterity 2.0 and the inclusion of it in Plone 4.3 was a lot of work. We all owe big thanks to David Glick, who did the lion's share of the work, and the many others who did smaller parts. And, thanks to the Framework Team for their diligent guidance.