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):

class a(PortalContent):

newob = a(id='fooid')

this won't cause any events to fire.  putting the object in place via:

somecontainer._setObject('fooid', newob)

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__

class aContentObject(PortalContent):
        def __init__(self) = 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!


Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to