[Product-Developers] dexterity and composition in models
matt.halstead at gmail.com
Thu Apr 15 03:01:10 UTC 2010
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.
Zope interface schemas allow us to represent composition using Object
fields, but currently these are not handled well in add/edit forms. 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. 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.
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
More information about the Product-Developers