Posts tagged 'dexterity'

Buildout: order of ‘extends’ configuration files

Yet another word to the wise: take care of your ordering of the ‘extends’ configuration files within your buildout.  It makes complete sense, and especially so with respect to version pinning: the later configuration’s versions will be the last one applied.

So, it makes a lot of sense (in hindsight!) that this configuration, and the fact I have version pins in my base.cfg, isn’t going to end well:

[buildout]
extends =
    base.cfg
    http://good-py.appspot.com/release/dexterity/1.0b2

The Dexterity version pins are going to override the ones I have in my base.cfg.  This …

Bad relationships: RelationChoice, RelationCatalog and removed Dexterity content in Plone

Disclaimer: this post isn’t giving relationship advice (or..it is in some twisted way).  Unsurprisingly, removing content in Plone via the ZMI when Plone says something can’t be deleted is likely to cause problems.

In my case, the fact I removed a Dexterity-based container (“Project”) caused users to no longer add or edit content of my Project type.  The reason for this boiled down to my use of RelationChoice fields, in order link Projects to Person objects and vice versa.  The backend storage for the RelationChoice field is an instance of z3c.relationfield.index.RelationCatalog, and this keeps …

Plone, Dexterity, and Incorrect Widgets

A nice ‘gotcha’ is the distinction between Zope’s schema.Date and schema.Datetime. The difference is obvious and straightforward when the two terms are laid out side-by-side: one is for dates only and the other adds a time component. Where things fell down for me in my usage of these fields with a Dexterity-based content type in Plone is the human component. When these fields are mashed in together within a lot of other text/Python/names, it’s easy to miss those 4 little letters of ‘time’. This lead me trying to use a DatetimeFieldWidget when I really …

Plone and Dexterity: Working with computed fields

Today, we’re looking at how to utilise computed fields within a Dexterity-based content type. The specific use-case is that of having two separate fields (first name and surname, for a Person type, for example) generate the complete object title. The first part of this — having the title of the content displayed correctly — is pretty straight forward once you know what documentation to read and understand how things happen. The second part — having the ID of the content correctly generated to be first name/surname is slightly more complicated.

Title computation and display

Let’s look at the first part …