All, Following our rather lengthy discussion, I've made some changes to PLIP #10778, which I hope alleviate the concerns associated with this PLIP.
This is now ready for testing. I've piggy-backed on David's PLIP #9938 buildout (plips/plip9938-output-filters.cfg), since his improved transforms will use the plone.uuid API to be non-Archetypes-specific. I've offered to support him in that PLIP, so there may yet be some changes desired in the PLIP #10778 code (plone.uuid, plone.app.uuid and the plip10778-plone.uuid branch of Products.Archetypes), although "on its own", I think this PLIP is now ready for review. Instead of describing the changes from the "old" code, I'll try to explain how the PLIP is now structured: = plone.uuid = plone.uuid provides a simple API for generating and accessing UUIDs. The principal API is the IUUID() adapter factory, which can be used to return a (byte string) UUID. There is also an IUUIDGenerator utility to generate new UUIDs. The default implementation uses the standard library uuid.uuid1() method. plone.uuid provides a marker interface IUUIDAware. Objects with this marker are expected to be adaptable to IUUID. There is an @@uuid view which renders a UUID string for an IUUIDAware object. This is useful in TAL, for example. plone.uuid also provides a specialisation of IUUIDAware called IAttributeUUID. Types that provide this interface get an IObjectCreatedEvent handler that generates and assigns a UUID stored in an attribute on the object, plus an IUUID adapter that looks up this attribute. = plone.app.uuid = plone.app.uuid provides some Plone policy for UUIDs. It contains a catalog indexer (using plone.indexer) for IUUIDAware objects, using the IUUID adapter factory. The indexer name is "UID", to be compatible with the existing UID index/metadata. Therefore, there is (no longer) a separate catalog setup step, and no migration required for existing Archetypes based content. plone.app.uuid also provides a view, @@redirect-to-uuid, which can be passed a UUID on the traversal subpath. This is then looked up in the catalog, before a redirect response is sent to the object's current location. There are also some utility functions to find objects by UUID in various ways. = Archetypes = The branch of Products.Archetypes makes Archetypes use plone.uuid to generate its UUIDs. The net effect is that the plone.uuid and plone.app.uuid APIs work for all Archetypes content (without migration), but can also be made to work with other objects. Archetypes objects are marked with IUUIDAware (but not IAttributeUUID). This makes the indexer, and @@uuid and @@redirect-to-uuid views work. UUIDs are still stored (in the _at_uid attribute) and created (by voodoo-wielding elves) in the same way as before. The make_uuid() function, which generates new UUIDs, now delegates to the IUUIDGenerator utility[1]. There is no migration for old content, but there isn't any need: UUIDs are still strings, and can't collide, even though technically new content will use a different algorithm. I did some tests TTW with references created "before" and "after", and they worked fine. There is an IUUID adapter factory for IReferenceable (which covers all Archetypes objects and, insanely, reference objects[2]). This returns the Archetypes UUID as stored in the _at_uid attribute, just as the UID() method used to do. The UID() method now does "return IUUID(self, None)". This means that if someone wanted to implement a custom IUUID adapter, the UID() method would follow suit. In theory, we could probably deprecate context.UID() metod in favour of IUUID(context) (in Python code) and context/@@uuid (in TAL), but I'm not sure we'd want to. It's used quite a lot. The plone.uuid way is more broadly compatible, though. = Dexterity et. al. = This isn't really part of the PLIP, but if the PLIP is accepted, I'll add plone.uuid support for Dexterity objects. That'll be pretty easy: just mark them with IAttributeUUID. We probably also want a migration step that grants UUIDs to and re-catalogs old Dexterity content. Presuming David finishes his work on plone.outputtransforms, this means link-by-uid to Dexterity content becomes a reality. We can maybe also make the standard reference browser widget work for non-AT content. UUIDs also become a viable thing to store for portlets and tiles that want to reference content. I also think we should consider adding UUIDs to comments if the plone.app.discussion PLIP is accepted. Cheers, Martin [1] I also took the opportunity to remove some weird, unused code attempting to use a Linux kernel UUID generator in /proc. [2] Whoever though people would *really* need references to references deserves to be locked in a room with Jeremy Beadle for two days _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
