#9319: Merging archetypes.fieldtraverser into Product.Archetypes ----------------------------------+----------------------------------------- Reporter: thet | Owner: Type: PLIP | Status: new Priority: minor | Milestone: 4.0 Component: Archetypes | Resolution: Keywords: Archetypes, traverse | ----------------------------------+-----------------------------------------
Comment(by raphael): I'm not sure everybody understands the motivation behind this PLIP. At least as I understand it the development of archetypes.fieldtraverser has been initiated by the fact that our current machinery does NOT work for binary data when using AnnotationStorage (AS). AS on the other hand has several advantages over todays default (AttributeStorage) like better performance, lower risk of name clashes, possibility to turn fields into properties (in the Python sense) etc. At least for those reasons I'm using archetypes.fieldtraverser today already myself. The fact that archetypes.fieldtraverser also adds an expanded convenience API might come in handy but I'd consider that secondary. Now, this could continue as an add-on but (1) it has to monkey patch Archetypes quite a bit and that should be avoided (2) it would let us move to AnnotationStorage as default storage for all field types - and don't tell me Archetypes is going to die any time soon ;-) It's used so much in the wild that it will continue even after Plone itself moved away from it if only through all those add-ons that will then pull it in as a dependency. Therefore, I'm +1 on this PLIP. -- Ticket URL: <https://dev.plone.org/old/plone/ticket/9319#comment:10> Plone <http://plone.org> Plone Content Management System
_______________________________________________ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories