mrtopf.de

Suche
Close this search box.

Content Types with Dexterity (Plone Conference 2009)

David Glick is introducing Dexterity to us, the new way of doing content types in Plone. It is aimed at non-developers and developers.

What is a content type?

  • A way to categorize the items in your site
  • It has a Schema which is a list of fields
  • It has a workflow/permissions
  • It has custom view templates
  • misc settings, like placeful restrictions, comments, searchability, per-type portlet assignments

Content Management Framework (CMF)

  • Underlying framework for registering types and assigning workflows
  • CMFDefault contains sample types which used to be used by Plone
  • It is not schema-based though

Archetypes

  • Provided schema-based form generation
  • Basis of Plone’s current default content types (ATCT)
  • Not going away anytime soon

It has some ugly bits though.

Dexterity

Because of the drawbacks of AT, Martin Aspeli invented Dexterity.

Goals of Dexterity:

  • Make filesystem content type development sane
  • Make through-the-web content type development sane
  • Make it possible to switch back and forth between the two

The philosophy of Dexterity:

  • Reuse over reinvention
  • Small over big (e.g. AT is quite big, it’s all in one package)
  • Natural interaction over excessive generality
  • Real code over generated code
  • Zope 3 over Zope 2
  • Automated testing

Installing dexterity

It’s a normal python egg you add to your buildout (plone.app.dexterity). Right now only compatible with Plone 3 but work on Plone 4 is ongoing. Then of course you also have to install it inside your site. This will give you all the products and a Dexterity Control Panel.

Using dexterity

Inside the Control Panel you can create a new content type. Right after that you can add it to a plone site but it only has Title and Description. It also contains a default view which contains also lots of meta data fields.

With „Behaviours“ you can extend the functionality of the content type like choosing a better shortname etc. This is different from subclassing and schema extension. Behaviours are stored in the FTI, they can be switched on and off. Examples are thumbnail generation, versioning, ratings, „name from title“ etc.

In the FTI you now can disable the Metadata behaviour and enable the name from title-behaviour.

Now we need more fields. This can be done in the Schema tab. You can give it a title and a type. A field has lots of attributes you can edit then like if it’s required, if it’s read-only, the default value etc.

Rapid Prototyping

The Schema object in memory is directly modified, so changes take in effect immediately.

Modifying a typey

You can add, remove and rename fields through the web. But, values stored in exising instances will not be automatically removed or converted. So be careful.

Some more desired refinements

  • Custom add permissions
  • Show the „bio“ field in a separate fieldset

These cannot be done throught the web (not yet). So lets switch to the filesystem.

Filesystem roundtripping

Schema editing internally is done in XML, stored in the FTI. This can be imported and exported via GenericSetup. It also is converted into a Zope 3 Schema which is then used to edit content.

He then goes through the files which are inside an example dexterity product structure. E.g. the __init__.py stuff is gone and now works all via GenericSetup. There every type will have it’s own XML file which is the generated one we talked about earlier.

He also shows the Zope 3 schema with custom fields you can use and some dependencies like five.grok and others.

To make that fieldset you then have to change the Zope3 Schema by adding a fieldset and adding a list of the field names to that set.

There are also more form directives he doesn’t want to get into like widget, omitted, mode, order_before, order_after etc. Additionally you can set permissions for individual fields.

Custom view templates

To register a custom view you write:

from five import grok
class View(grok.View):
    grok.context(IPlonista)
    grok.require('zope2.View')

Templates are found by convention (thanks to grok). So you need to put it into „plonista_templates/view.pt“. Inside the template you also can use direct attribute access as dexterity is intelligent enough to find that data.

Enabling your filesystem content type

You can then add the package to your buildout and rerun buildout.

After restarting Plone you can e.g. see the Bio field in a separate fieldset and you also see the custom view.

The pieces

  • five.grok
  • plone.dexterity (core package, base content classes, FTI, default edit form and view)
  • plone.autoform (Dexterity renders widgets using z3c.form, autoform makes it possible for a form to be composed by schemas and form hints from different sources, like main schema + behaviour schemas)
  • plone.schemaeditor (used for UI for editing schema TTW. basically you can edit a Zope3 interface TTW. could be used seperately. IFieldFactory determines which fields are editable)
  • plone.supermodel (serializer translates Zope3 schema into XML. Parser translates an XML schema into a Zope 3 Schema. It’s easily extensible)
  • plone.directives.dexterity (grok directives for custom content classes)
  • plone.folder (orderable btree-based folder implementation, will also be the basis for AT-based folders in Plone 4)
  • plone.behaviour (a behaviour is a conditional adapter. In Dexterity, the condition is whether the behaviour is listed in the FTI for a type. ZCML directives for registering new behaviours)
  • plone.rfc822 (supports marshalling of Dexterity contet into RFC 822 format, used to support access via WebDAV)
  • plone.app.dexterity (pulls in everything you need. Standard behaviou: DC, related items. Provides the types control panel)

Status/Roadmap

  • Core functionality is pretty solid
  • Schema serialization
  • automatic form generation seems to be working will
  • portlet assignments works
  • content rule assignments works
  • Relations not working between AT and Dexterity content types in the same site
  • Widgets nor as rich as AT yet but better than formlib. We have autocomplete, browser-for-content, file/image upload
  • TTW schema editing works fine but needs more real-life use
  • Image & File support (via plone.namedfile & plone.formwidget.namedfile). No support for image scaling yet.
  • Rich Text field with text transform support
  • Select field support. no way to define vocabularies through the web yet.
  • WebDAV support is work in progress.
  • Versioning and staging is in progress
  • TTW behaviour creation would be cool but is not yet implemented.
  • Link integrity checks are not implemented yet

Upcoming releases

Second alpha release was on Oct 12. First beta release coming soon.

It’s compatible with Plone3, Plone 4 compatibility is coming soon.

Documentation

Dexterity Developer Manual
Behaviours manual

Getting involved

Code on Google
Google Group

Teile diesen Beitrag