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
