Am 12.02.2008 um 17:55 schrieb Miles Waller:
The subscribers are already wired up for anything IContentish in
CMFUid's event.zcml, provided the uid tools are also in your portal.
I think there are two things going on:
1. The events are only fired when the object is put into place in a
container, rather than when instantiated. For example (very roughly):
newob = a(id='fooid')
this won't cause any events to fire. putting the object in place via:
will make the events fire. I don't know if aFactory does the
setting in place, but in your code snippet you don't give it a
container so I am guessing not. Where are you running the code
snippet that you pasted?
I was running it in zopectl debug. aFactory is currently pretty much
as plain as your example.
2. a.getId() will return the id of the object, not its uid. To get
its uid use a.cmf_uid(), or more correctly something like
portal_uidhandler.getUid(a) - this will return the uid values.
ah, so an object's id is not (necessarily) the same as it's uid? So
when adding an object to a container I always need an id? If I needed
to generate the id's automatically how would I go about this? Call
portal_uidgenerator() directly? Presumably in my __init__
self.id = portal_uidhandler.register(self)
I realise now (and perhaps for the first time) the difference between
an object's id in it's container and the possibility it has a UID for
direct access from other contexts. I guess the question then is it
advisable to rely on the UID like this? or would it be preferable to
generate a different kind of id? or whether it's a moot point if
access to the object is always mediated?
Hope that helps,
Yes, it does. Thank you very much!
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests