On Fri, Jun 6, 2008 at 7:24 AM, Fred Drake <[EMAIL PROTECTED]> wrote: > Still another approach, if you're looking to create software support > and the first isn't suitable, is to use fields that provide additional > interfaces that indicate the nature of the references.
My application (and I suspect other cases will) need to do just this; a marker on the field eliminates the ambiguity. Schema and interfaces should allow for complete "domain modeling" in such a way that expresses intent of the business case, regardless of the persistence mechanism or implementation details underneath, so I think I'll continue to use custom field types marked with an IRelationshipField interface, and assume the built-in Object, List fields are only used for containment. The only thing I do not like about my direction is that it leaves ambiguity when working with code from other components/projects that do not share this assumption. For RDBMS persistence of schema-defined content, z3c.dobbin (for example) assumes Object fields are just foreign-key relationships, but the downside to this simplification is an inability to meaningfully interact with a simple persisted containment scenario (a complex object that has contained specialized child objects intrinsically part of the primary object; trying to serialize to JSON with clear recursion boundaries for example, would be difficult). In my application-case, I'm looking to do something similar, but hoping to do so with a clear bright-line between associations and containment. Note: removal of such ambiguity is helpful for the possible use case of schema/interface bootstrapping/generation from UML tools for model-driven-design. Sean _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )