[Product-Developers] dexterity and composition in models

Martin Aspeli optilude+lists at gmail.com
Thu Apr 15 04:18:54 UTC 2010

Hi Matt,

On 15 April 2010 11:01, matth <matt.halstead at gmail.com> wrote:
> Hi,
> I keep running into a problem with composition in content types, and
> now that I am using Dexterity it is highlighted even more.
> There is a general notion that composition in zope is implemented
> through containment, although in Archetypes we do have the
> DataGridField and CompoundField which allow for composition type
> implementations not requiring containment.

That's a little wrong: DataGridField is just storing a list of lists,
much the same as a Lines field stores a list or a String field stores
a string. I don't know how CompoundField works.

OTOH, references are another way to implement one-to-many.

> Zope interface schemas allow us to represent composition using Object
> fields, but currently these are not handled well in add/edit forms.

Right. I wouldn't use them unless you're building a custom UI to
add/edit. Sometimes it's a useful thing to specify in an interface,
but probably not for a content type interface.

> So
> we are left with representing composition as contained objects and
> which is not represented in the 'dexterity' model, but will be in the
> generic setup type configuration.

Yes. But the point here is not whether it's "represented in the
schema", but whether it's represented in the content hierarchy. If you
model containment, it means you want to use the "add" menu to add
children etc.

If you're really modelling something that's just a property that is a
list of more complex objects, you should represent it on the schema.
However, no standard widget is likely to be useful, so you'll need to
build your own widget.

> I notice though that Dexterity makes
> a good job of collections of simple data types, which has some similar
> UI issues resolved.


> A particular problem with implementing composition as containment is
> that by default the catalog will index these objects as separate
> objects leaving the developer to jump through hoops in removing these
> from being individually indexed and adding some method to the parent
> class to index them, or instead placing conditions in those areas
> where catalog results are used (search results and navigation mainly)
> to either not render or to render the parent.

Again, this is more of a problem of the basic use case. If your data
is hierarchical and should be represented as a container with children
in the Plone UI, then you have a standard parent/child content
relationship. Otherwise, you have to do something else.

> It feels like a lot would be gained by allowing composition to be
> defined in schemas and implemented as properties on objects, and all I
> can see is that there is a lack of machinery in the add/edit form
> rendering to support this by default. Is this the only thing making
> this difficult out of the box or are there other considerations?
> (apart from the usual assurances that these objects would be
> persistent aware).

A List with value_type Object works. I think in the most recent
z3c.form, it even attempts to render some widget. But it's mega ugly
and confusing. Trying to build a generic widget for this kind of thing
would be quite challenging, though I'm sure it'd be possible to do a
better job than what z3c.form does right now.

Note that in this case, the "many" part of the relationship is *not*
going to be a content object. Most likely, it'll be a simple object
deriving from Persistent and implementing a particular schema
interface. It won't have security, traversal, role management, a URL,
or any of the other things you want for content.


More information about the Product-Developers mailing list