Uses setattr to set a simple attribute in a content type in Plone - bad practice (I mean, will this haunt me in the future)?

Question

I have two different contexts for a Plone instance.

In the first context there are some ATFolders. Secondly, there are also ATFolders that need to be synchronized with the first context using some subscribers.

In the second context, ATFolders should be aware that they are associated with some folders in the first context.

I was thinking about using setattr in them ( setattr(obj_context1, attr, obj_context2.UID()) ) instead of creating a new Content-Type just to have the ReferenceField attribute (or using archetype.schemaextender ), since that would be too much redundant for just one parameter in a certain context: folders that will have this attribute will not be deleted, for example, from ZODB. They will have a convenient one-state workflow. This attribute is completely hidden from the user, and folders in the second context are programmatically created without user intervention.

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

I tend to use setattr for the sake of pragmatism in this particular scenario, but I don’t know if using the setattr approach setattr haunt me in the future (performance, conflicts in architects, etc.)). I mean: if you make an update catalog, update workflow, will this new attribute have a problem?

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

Answer 1

I don’t think this is bad practice at all, I do similar things for similar situations.

You can use attribute annotation to help prevent conflicts with other attributes, but style and performance choices are more than anything else. Attribute annotations are stored in their own ZODB record, so it depends on how often this attribute will change compared to other attributes in the folder, what effect it has.

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

Other notes. We also used plone.app.relations connections between objects in the past (supported outside the object schema, for example, your attribute), but found five.intid (the underlying .relations mechanism) is too fragile and will use simple UID attributes with directory .relations in the future.

In response to Ross's answer, if the information in question does not need to be edited for the end user, the schemaextender attribute overflows.

Answer 2

Maybe use archetypes.schemaextender ? See also this document . Thus, you can use the actual ReferenceField, get all kinds of materials for free and spend much less time on the re-implementation of the specified free material.