Sections
You are here: Home Integrators & Developers Tips for Archetype-based Content Types

Tips for Archetype-based Content Types

Useful things to know about archetype based content types.

Getting Started

ArchGenXML used to be the way to generate content types, however nowadays, lots of people use paster (especially as this comes bundled with the universal installer).

There's an introduction here, which will get you to the point of generating a product and a content type:

http://plone.org/documentation/kb/creating-a-content-type-for-plone-3-for-developers

Alternatively you might want to look at the new Packt Plone Development Cookbook (page 100) - which will also get you to the point of dropping this product into your buildout.

Sub-Classing

The Development Cookbook also runs you through the possibilities for sub-classing your content type on something a little more sophisticated than the basic base ATCTContent (e.g. the ATDocument content type).

It always helps at this point to know what you're getting when you sub-class, so have a look at Products.ATContentTypes in buildout-cache/eggs. All the content stuff is in the content directory - so for instance you'll find the ATDocument stuff in content/document.py.

Every content type comes with a title and a description automatically. It probably makes sense to map some aspect of the content you're modelling to those two fields (you can relabel them if you want).

Controlling the Edit Layout

The Editing form will be generated automatically by the Archetypes framework. If you really want to, you can actually override the edit template, but there are a few tweaks you can make in the class itself which will ensure you don't necessarily have to fiddle with the edit template.

As you'll be inheriting a few fields from the content type you're sub-classing, you'll probably want to shuffle your fields around a bit and you might want to re-label or re-describe the Title and Description fields. Here are some examples (where job_schema is the name of the schema generated by paster [and comprises your schema plus the sub-classed content type schema]):

Re-Labelling

job_schema['description'].widget.description = "Use this for the salary and 
other information or use the fields below"
job_schema['title'].widget.label = "Job Title"

Re-Ordering

Normally, the fields from the content type you're sub-classing appear first in the list, then you'll get the fields you've created, in the order they appear in the class definition:

job_schema.moveField('text', before='jobNumber')
job_schema.moveField('description', after='salaryDetails')

Schemata (or Field Categories)

Not to be confused with schema (the field definition), schemata are the categories fields are assigned to, the standard ones are Default, Categorization, Dates, Ownership, Settings (that's the blue and white bar of links).

You can create your own by just adding:

schemata = 'MySchemata'

to each field definition.

Here's how to move the expiry date to the Default schemata - you may have to use some trial and error to get it in the right place in the editing layout.

job_schema['expirationDate'].schemata = "Contact"


I found out the name of this field by poking around in content/schemata.py in Products.ATContentTypes (where incidentally it shows you a different way of moving fields around).

Hiding a Field

job_schema['spareField'].widget.visible={'view':'invisible', 'edit':'invisible'}

The finalizeATCTSchema trap

You'll see a line of code in your content type generated by paster:

finalizeATCTSchema(job_schema)

This does some shuffling of fields in itself - you can actually see what it does in content/schemata.py. So, if the results are not quite what you wanted, then make sure your lines of code come after this line, not before.