Is using setattr to set a simple attribute in a content-type in Plone a bad practice (I mean, is it going to haunt me in the future)?

Question

I have two different contexts on a Plone instance.

The first context has some ATFolders. The second, have ATFolders too that have to be in sync with the first context using some subscribers.

In the second context, the ATFolders have to know that they are linked to some of the folders on the first context.

I thought about using setattr in them (setattr(obj_context1, attr, obj_context2.UID())) instead of creating a new Content-Type just to have a ReferenceField attribute (or using archetype.schemaextender), since this would be too much overkill for just a single parameter in a specific context: the folders that will have this attribute will not be deleted from ZODB for example. They will have a placeful workflow with just one state. This attribute is completely hidden from the user, and the folders on the second context are programatically created, with no user intervention.

This attribute should only exist in the second context, so creating an adapter or a new content-type, just to be used in this context seems to be too much.

I'm inclined to use setattr for the sake of pragmatism on this specific scenario, but I don't know if using the setattr approach is going to haunt me in the future (performance, zodb conflicts, etc). I mean: doing an update catalog, update workflow, is this new attribute going to have a problem?

Any thoughts? Anyone experienced with setattr in this situation? This attr will and should not be visible, it's only for some control.

Answer 1

I don't think it's bad practice at all, I do similar things for similar situations.

You could use an attribute annotation, which would help prevent conflicts with other attributes, but that's a style and performance choice more than anything. Attribute annotations are stored in their own ZODB persistent record, so it depends on how often this attribute will change compared to the other attributes on the folder what impact this has.

Last but not least, I would probably encapsulate the behaviour in an adapter, to make the implementation flexible for future uses. You can either register the adapter to the ATFolder interface, or to IAttributeAnnotatable, depending on how much your implementation relies on what the adapted object needs to provide.

Other notes: We've also used plone.app.relations connections between objects in the past (maintained outside the object schema, like your attribute), but found five.intid (the underlying machinery .relations relies on) to be too fragile and would use simple UID attributes with catalog searches in the future.

In reference to Ross's answer, if the information in question doesn't need to be end-user editable, a schemaextender attribute is overkill.