How to add custom content types

  Can someone please point me to a HOWTO that shows a *simple* way to add
  say a person object with the attributes firstName, lastName to the [ZODB (Zope Object Database)]
  in Zope? I have found docs that talk about how to do it with a
  standalone [ZODB (Zope Object Database)] but not Zope itself. The Zope docs gloss over this in
  favour of using a SQL RDBMS...  No - perhaps I can use another
  example. Take a book database. We have a class book with attributes
  title and author. I want to persist those in the [ZODB (Zope Object Database)]. I feel like I am
  so close to understanding this but invariably end up in a never ending
  circle of ZClass/ZPT, etc.

There's more than one way to do it

This page tries to enumerate the solutions to this common question. It would be nice to have a walk-through example for each. Please update.

Vanilla zope

• 1. use standard Zope objects
• 2. use ZClasses
• 3. write your own [Disk-based product] (disk-based)

Zope + products

• 4. use standard CMF/Plone content objects
• 5. use Formulator
• 6. use TTWType
• 7. use CPSSchemas
• 8. use Archetypes (disk-based)
• 9. use wiki pages or other textual type (adhoc)
• 10. use search keywords (adhoc)

Solutions

1. use standard Zope objects
Zope provides a number of standard object types out of the box, with a default set of attributes which appear in the ZMI (Zope Management Interface) properties tab. As a hackish solution you could look for a suitable standard object with enough unused properties that you could repurpose. You could make your own management forms; go to the object's ZMI (Zope Management Interface) properties tab and "view source" as a starting point. You could make your forms/scripts add additional attributes by calling manage_addProperty (?).

2. use ZClasses
Define custom object classes in the ZMI (Zope Management Interface). Old/deprecated, maybe still right for some

3. write your own Disk-based product
gives complete flexibility

4. use standard CMF/Plone content objects
Like 1, but the standard CMF/Plone content types come with a richer set of properties (see the metadata tab). As it happens, title and author are standard properties.

5. use Formulator
possibly ? old

6. use TTWType
requires CMF/Plone

7. use CPSSchemas
requires CMF/CPS, flexible storage

8. use Archetypes
automatic form generation, minimal programming, flexible storage

9. use wiki pages or other textual type
Rather than defining fixed fields, you might also represent attributes in a more adhoc/fluid way as freeform text, eg in the body of a Document or ZWiki page. Eg include Attribute: value pairs, or tag a page with one or more 'WikiBadge?'s. Note even though attributes are stored within a freeform field you can still write small scripts to expose them for indexing and then do structured ZCatalog? searches, etc.

10. use search keywords
Tag objects with one or more meaningful search keywords in the CMF metadata tab (?)

See also TypesAndFormsTools.

If your custom objects represent users and you want to use them for authentication, there is a different class of solutions you should be looking at involving UserManagementProducts, portal_memberdata etc.

Some definitions:

Vanilla Zope

Standard Zope with no add-ons. This is what you'll see covered in the core Zope docs.

Zope + products

There are useful add-on Products guide which can be installed to help with this.

Through the web (TTW)

Through-the-web solutions can be done all in your web browser. Usually no python programming is required. The solutions below are through-the-web unless otherwise noted.

Filesystem-based, disk-based

This means you develop some kind of ZopeProduct on the file system. These tend to be more maintainable over the long term than TTW solutions. Python programming ability is required.

Structured

Solutions which define a formal data type, with fixed fields, special forms etc. for your content. Most of the solutions below are of this type.

Adhoc

Solutions which re-use some existing data type, perhaps using free-form text, and without fixed fields.

Flexible storage

This means you have the option of storing data in a RDBMS or elsewhere; otherwise data is stored in the ZODB (Zope Object Database).

Classless

Solutions 1, 4 and 9 are classless or prototype-based - you or your forms must ensure objects representing books have the correct attributes. If you change your objects' attribute schema, you'll need to update all objects accordingly.

Class-based

All the others are class-based: there is a class, defined by you or already existing, giving your book objects a distinct type and ensuring they all have the correct attributes.

comments:

page needs an update --simon, Fri, 20 May 2005 08:36:22 -0700 reply
ATVocabularyManager is apparently AT schemas through the web.

new --simon, Sun, 28 Aug 2005 20:52:14 -0700 reply
Check out AbracadabraObject? , PropertyTools? and [iungo]?.