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. 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 persistent aware). cheers Matt _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
