CMFUid introduces a simple unique id implementation.
Implementation
==============
The supplied tools attach the unique ids to the objects. The objects
do not have to be aware of unique ids.
The current implementation depends on the portal catalog to find an
object of a given unique id. The interfaces do not imply the use
of the catalog (except the IUniqueIdBrainQuery).
Which Tool does What?
=====================
The portal_uidgenerator tools responsibility is to generate
unique ids. The portal_uidannotation tool is responsible to
attach unique ids to a content object, and enforce rules about
what happens on object move/create/delete. The portal_uidhandler
manages registering and accessing unique ids.
This design was chosen to allow users replacing only parts of
the functionality without having to understand the whole thing.
Unique Id API
=============
portal_uidhandler implementing IUniqueIdHandler is the main
API for playing with unique ids.
Usage
=====
portal_uidhandler fully implements IUniqueIdHandler (IUniqueIdSet
for registering/unregistering unique ids, IUniqueIdQuery for queries
and IUniqueIdBrainQuery for more efficient queries by returning
catalog brains instead of objects).
The current implementation of get/queryBrain and get/queryObject
do not return invisible objects (and brains of invisible objects).
By invisible objects, we mean objects that would be filtered out
by portal_catalog.searchResults due to expiry/effective date and/or
user roles.
It is often necessary to avoid this filtering in an application.
To do this, use the unrestrictedGet/QueryBrain and
unrestrictedGet/QueryObject as this will avoid None results.
Have a look at the interfaces.
CMFUid's functionality is used by CMFDefault's favorite content type
to follow linked objects. The favorite content type works as before if
CMFUid is not installed.
|
Forgot your password?
New user?
python2-zope.untrustedpython-4.0.0-1.lbn19.noarch
Builder
