Является ли использование setattr для установки простого атрибута в типе контента в Plone плохой практикой (я имею в виду, будет ли это преследовать меня в будущем)?

Question

У меня есть два разных контекста в экземпляре Plone.

В первом контексте есть несколько ATFolders. Во-вторых, есть ATFolders, которые должны синхронизироваться с первым контекстом с использованием некоторых подписчиков.

Во втором контексте ATFolders должны знать, что они связаны с некоторыми папками в первом контексте.

Я думал об использовании setattr в них (setattr(obj_context1, attr, obj_context2.UID())) вместо создания нового Content-Type просто для того, чтобы иметь атрибут ReferenceField (или использование archetype.schemaextender ), поскольку это было бы слишком Значительное превышение для одного параметра в определенном контексте: например, папки, которые будут иметь этот атрибут, не будут удалены из ZODB. У них будет рабочий процесс с одним состоянием. Этот атрибут полностью скрыт от пользователя, и папки во втором контексте создаются программно , без вмешательства пользователя.

Этот атрибут должен существовать только во втором контексте, поэтому создание адаптера или нового типа контента для использования в этом контексте представляется слишком сложным.

Я склонен использовать setattr ради прагматизма в этом конкретном сценарии, но я не знаю, собирается ли использование подхода setattr преследовать меня в будущем ( производительность, конфликты zodb и т. д.). Я имею в виду: делать каталог обновления, обновлять рабочий процесс, у этого нового атрибута будет проблема?

Есть мысли? Кто-нибудь сталкивался с setattr в этой ситуации? Этот атрибут будет и не должен быть видимым, он только для некоторого контроля.

Answer 1

Я не думаю, что это вообще плохая практика, я делаю похожие вещи для похожих ситуаций.

Вы можете использовать аннотацию атрибута, которая поможет предотвратить конфликты с другими атрибутами, но это стиль и производительностьВыбор больше всего на свете.Аннотации атрибутов хранятся в их собственной постоянной записи ZODB, поэтому это зависит от того, как часто этот атрибут будет меняться по сравнению с другими атрибутами в папке, как это повлияет.

И последнее, но не менее важное: я бы, вероятно, инкапсулировалповедение в адаптере, чтобы сделать реализацию гибкой для использования в будущем.Вы можете зарегистрировать адаптер в интерфейсе ATFolder или в IAttributeAnnotatable, в зависимости от того, насколько ваша реализация зависит от того, что должен предоставить адаптированный объект.

Другие примечания: Мы также использовали plone.app.relations соединения междуобъекты в прошлом (поддерживаемые вне схемы объекта, как ваш атрибут), но обнаруженные five.intid (базовый механизм, на который опирается .relations) слишком хрупкие и будут использовать простые атрибуты UID для поиска в каталоге в будущем.

В отношении ответа Росса, если рассматриваемая информация не нуждается в редактировании конечным пользователем, атрибут schemaextender является избыточным.

Answer 2

Может быть, использовать archetypes.schemaextender ?Смотрите также этот документ .Таким образом, вы можете использовать реальное ReferenceField, получать все виды вещей бесплатно и тратить намного меньше времени на повторную реализацию этих бесплатных вещей.