Re: [Zope] zope.schema: association vs. containment in Object, List
On Fri, Jun 6, 2008 at 7:24 AM, Fred Drake <fdrake@gmail.com> 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
On Fri, Jun 6, 2008 at 8:08 PM, Sean Upton <sdupton@gmail.com> wrote:
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
I'd rather not make any assumption at all; use two interfaces: one that indicates references, and one that indicates containment. That allows you to raise an exception for fields that don't specify, which would be useful during testing and debugging. For each such field found, you'll get to decide how to handle it and stamp the appropriate interface on the field. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Fri, Jun 6, 2008 at 7:26 PM, Fred Drake <fdrake@gmail.com> wrote:
On Fri, Jun 6, 2008 at 8:08 PM, Sean Upton <sdupton@gmail.com> wrote:
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
I'd rather not make any assumption at all; use two interfaces: one that indicates references, and one that indicates containment. That allows you to raise an exception for fields that don't specify, which would be useful during testing and debugging. For each such field found, you'll get to decide how to handle it and stamp the appropriate interface on the field.
Makes sense, so I would have two subclasses of zope.schema.Object, one for containment, another for association -- each with respective interfaces and validation behavior. Explicit declaration of intent for each field is what I'm aiming for anyway. Thanks. Sean
participants (2)
-
Fred Drake -
Sean Upton