So you’ve probably heard of the upcoming Emerald Sprint, and that we’re going to be working on the Dexterity content type system for Plone. But you may be thinking: “As a developer, I already use Dexterity. I heard the Wine and Beer sprint produced a release of plone.app.contenttypes that will make ATContentTypes obsolete. Hasn’t Dexterity already arrived?”
Well, it has. But it hasn’t. Here’s why: As a replacement for Archetypes for filesystem-based Plone development, Dexterity has basically arrived. But as a through-the-web rapid app development tool, there’s still a lot of work to do.
There is a particular sort of basic web app that Plone is particularly well suited to, which T. Kim Nguyen and Nathan van Gheem have dubbed the “workflow app.” This is an app which has:
- a content type (or several) with custom fields for data entry
- a workflow that defines steps for submission, review, and publication of the content
- customizable views for browsing, listing, searching, and viewing the content
Most Plone developers with more than a few months of experience have probably built one or two of these, and know that Plone provides a reasonable toolset for getting the job done. But here’s the thing: 90% of a typical workflow app does not have unique requirements, and we should strive to make that 90% accomplishable through-the-web without custom programming. How many times have you built a custom form for a client, only to later face an uncomfortable conversation when they want to change something “trivial” like wording or order of the fields? Those sorts of changes should not require the assistance of a developer, and our clients will be happier and more enthusiastic users of our systems if we can provide them with tools that empower them to do that sort of configuration on their own.
It’s not just for the users. As developers, we reap benefits when we take the time to build systems that empower non-developers. For one thing, life is too short to spend it building the same sort of software over and over again. When we stop repeating ourselves and focus on identifying recurring needs and engineering reusable (read: well-tested, documented, configurable, and extensible) systems, we end up with more interesting programming challenges and more happiness with our work. We also add to the pool of people who would like to draw on our expertise in the system, because there are more people who were able to build something useful and get their foot in the door with the system without facing a huge learning curve or an early need for a developer’s expertise.
Okay, so, back to workflow apps. There are already some existing tools for building them within the Plone ecosystem–Dexterity’s competitors, if you will: PloneFormGen (with uwosh.pfg.d2c to save form submissions as content items) and Plomino. I have a lot of respect for these tools, as they have fewer limitations than through-the-web Dexterity at present, and manage to accomplish some similar goals. But my problem with them is this: they use their own data model, and they are focused *only* on through-the-web development, without a smooth path for extending types built through-the-web using code on the filesystem. Dexterity wins here because it gives each type a real Zope interface and schema which can be used by developers once some beyond-the-90% requirements are needed. You can build a Dexterity content type through the web or you can write it in code, and either way you end up working with the same sort of thing.
So what do we need to add to Dexterity to get its feature set to the point where useful workflow apps can be built?
- We need to support more types of fields in the TTW type editor. For example:
- Email fields that come with built-in validation and render themselves with a link in display mode.
- Relation fields including specifying what types may be selected and where in the site to start browsing.
- Data grid fields with multiple columns.
- We need to support TTW configuration of indexes. At the least, we need to include the functionality from collective.dexteritytextindexer to choose which fields are included in the SearchableText index. But it would also be nice to easily create field-specific indexes, since that is the basis for querying fields in things like collections and eea.facetednavigation.
- We need to support TTW configuration of validators. I am mostly thinking in terms of selecting from predefined types of validators like “is equal to” or “matches regexp” or “is unique.”
- We need a way to define custom views and forms so that content types can be presented in nice ways. As Asko blogged a week ago, this is already possible by creating templates in portal_skins, but that’s not very obvious. The content type editor should have a Views tab that lists the configured views and allows adding and editing new ones. At its most basic, it could be editing TAL templates, with some inline help on how to insert fields. A more sophisticated view editor could be along the lines of Deco and allow WYSIWYG placement of fields.
- We need to integrate the workflow editor in plone.app.workfloweditor. In the Dexterity type editor, there should be a Workflow tab where the type’s workflow can be edited.
- We need to streamline exporting TTW content type configuration to filesystem packages. This is needed so that once something is prototyped it can be installed on a production site. It’s currently possible to export the type configuration as a GenericSetup profile, but it would be useful to export an entire Python package.
- We need tools to help with importing and exporting data. I’m thinking of things like a browser view that lets you upload CSV and map columns to fields in a content type. Or views of containers and items to export content as JSON.
That’s just a start, but it would be quite the start! Over the next days I’ll be filling in some details of how to approach some of these on the sprint Trello board. If you won’t be at the sprint but would like to support these efforts, please consider chipping in to help cover the expenses of the sprint. Thanks!