在 Plone 中使用 setattr 在内容类型中设置简单属性是一种不好的做法吗（我的意思是，它将来会困扰我吗）？
我在 Plone 实例上有两个不同的上下文。
第一个上下文有一些 ATFolders。第二个，也有 ATFolders，必须使用一些订阅者与第一个上下文同步。
在第二个上下文中，ATFolders 必须知道它们链接到第一个上下文中的某些文件夹。
我考虑在其中使用 setattr (setattr(obj_context1, attr, obj_context2.UID()))，而不是创建一个新的 Content-Type 只是为了具有 ReferenceField 属性 (或使用 archetype.schemaextender），因为这将是在特定上下文中，仅单个参数就太过分了：例如，具有此属性的文件夹将不会从 ZODB 中删除。他们将拥有一个只有一种状态的固定工作流程。此属性对用户完全隐藏，并且第二个上下文中的文件夹是以编程方式创建的，无需用户干预。
这个属性应该只存在于第二个上下文中，因此创建一个适配器或一个新的内容类型，只是为了在这个上下文中使用似乎太多了。
在这个特定场景中，我倾向于使用 setattr 来实现实用主义，但我不知道使用 setattr 方法是否有效将来会困扰我（性能、zodb 冲突等）。我的意思是：做一个更新目录，更新工作流程，这个新属性会不会有问题？
有什么想法吗？有人在这种情况下经历过 setattr 吗？这个属性将会并且不应该是可见的，它只是为了一些控制。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这根本不是不好的做法，我在类似的情况下做了类似的事情。
您可以使用属性注释，这将有助于防止与其他属性发生冲突，但这是一种风格和性能选择。属性注释存储在自己的 ZODB 持久记录中，因此这取决于该属性相对于其他属性的更改频率，对文件夹有何影响。
最后但并非最不重要的一点是，我可能会将行为封装在适配器中，以使实现灵活以供将来使用。您可以将适配器注册到 ATFolder 接口或 IAttributeAnnotable，具体取决于您的实现对适配对象需要提供的内容的依赖程度。
其他注意事项：我们过去也使用过对象之间的
plone.app.relations连接（在对象模式之外维护，如您的属性），但发现Five.intid（.relations所依赖的底层机制）太脆弱了，将来会在目录搜索中使用简单的 UID 属性。参考罗斯的回答，如果相关信息不需要最终用户可编辑，那么 schemaextender 属性就有点过分了。
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.relationsconnections between objects in the past (maintained outside the object schema, like your attribute), but foundfive.intid(the underlying machinery.relationsrelies 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.
也许使用archetypes.schemaextender？另请参阅此文档。这样您就可以使用实际的 ReferenceField，免费获得各种东西，并花费更少的时间重新实现所述免费的东西。
Maybe use archetypes.schemaextender? See also this doc. This way you can use an actual ReferenceField, get all sorts of stuff for free, and spend a lot less time re-implementing said free stuff.