[Product-Developers] Re: dexterity and composition in models

matth matt.halstead at gmail.com
Thu Apr 15 05:48:19 UTC 2010


Hi Martin,

On Apr 15, 4:18 pm, Martin Aspeli <optilude+li... at gmail.com> wrote:
> Hi Matt,
>
> On 15 April 2010 11:01, matth <matt.halst... 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.

Sorry I was meaning ArrayField, along with CompoundField.

> I don't know how CompoundField works.
>
> OTOH, references are another way to implement one-to-many.

They work well for aggregation and other associations, composition
(where containment hierarchy is not what you are after) I think is
better represented and implemented through an Object field (or
collection of Object fields).

>
> > 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.

Sure, I want both, I don't really want to model some composition
relationships as containment just to get some UI for adding/editing.

>
> 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.
>
> Right.
>
> > 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.

You're right, that does actually work, in terms of rendering the form
pieces, just not the handling of the data submitted and creation of
the right class instances it seems.

>
> 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.

That's exactly what I don't want it to have, the object that owns this
will need to have plenty of knowledge about this kind of property.

Thanks for your reply, very helpful.

Matt


>
> Martin
>
> _______________________________________________
> Product-Developers mailing list
> Product-Develop... at lists.plone.orghttp://lists.plone.org/mailman/listinfo/product-developers




More information about the Product-Developers mailing list