我在Plone实例上有两个不同的上下文.
第一个上下文有一些ATFolders.第二种,也有ATFolders,必须使用一些订阅者与第一个上下文同步.
在第二个上下文中,ATFolders必须知道它们与第一个上下文中的某些文件夹相关联.
我考虑过使用setattr它们(setattr(obj_context1, attr, obj_context2.UID()))而不是创建一个新的Content-Type只是为了拥有一个ReferenceField属性(或使用archetype.schemaextender),因为这对于特定上下文中的单个参数来说太过分了:文件夹那个例如,将不会从ZODB中删除此属性.只有一个州,他们将拥有一个统一的工作流程.此属性对用户完全隐藏,第二个上下文中的文件夹以编程方式创建,无需用户干预.
此属性应仅存在于第二个上下文中,因此创建适配器或新内容类型只是在此上下文中使用似乎太多了.
我倾向于使用setattr为求实用主义在这种特定情况下,但如果使用我不知道setattr的方法是要缠着我的未来(性能,ZODB冲突等).我的意思是:做一个更新目录,更新工作流程,这个新属性会出现问题吗？
有什么想法吗？setattr在这种情况下有经验的人吗？这个attr将会也不应该是可见的,它仅用于某些控制.
我认为这根本不是很糟糕的做法,我也会为类似的情况做类似的事情.
您可以使用属性注释,这有助于防止与其他属性发生冲突,但这是一种风格和性能选择.属性注释存储在它们自己的ZODB持久性记录中,因此它取决于此属性与文件夹上的其他属性相比更改的频率.
最后但并非最不重要的是,我可能会将行为封装在适配器中,以使实现灵活,以备将来使用.您可以将适配器注册到ATFolder接口,也可以注册到IAttributeAnnotatable,具体取决于您的实现依赖于适配对象需要提供的内容.
其他说明:我们过去也使用plone.app.relations了对象之间的连接(在对象模式之外维护,比如你的属性),但是发现five.intid(底层机器.relations依赖)太脆弱了,并且会使用简单的UID属性和目录搜索.未来.
在参考Ross的答案时,如果相关信息不需要是最终用户可编辑的,那么schemaextender属性就会过度.
| 归档时间： |
|
| 查看次数： |
381 次 |
| 最近记录： |