+-------[ Stefan H. Holek ]---------------------- | At 01.02.2002 10:44 -0500, R. David Murray wrote: | | All, | | Please have a look at my patch for XUF at | <http://www.zope.org/Members/shh/Patches/exUserFolder-0.10.4.patch> | | I believe that manage_addexUserFolder() is faulty, in that it does not call | the FactoryDispatcher's this() before assigning to self.__allow_groups__. | | My point is that 'self' is initially referring to a FactoryDispatcher | (App/FactoryDispatcher.py) which does *not* define __setattr__().
As I explained previously I think that if you are trying to install XUF (or anything) programmatically from a ZClass, then you should call the manage_addFoo() on an instanciated object i.e. a Folder or some other container that your ZClass has created, not on your Dispatcher. If someone gives me a sane reason why this isn't correct and that calling self = self.this() in every product constructor is actually the correct behaviour I'll put it in (as opposed to catering for lazy ZClass programmers d8) Not that this seems to be in very many constructors for Zope stuff or other products I have installed. Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call self.Destination()._setObject() so in essence self.Destination().__allow_groups__ will also get what we want. This is actually documented (although it's not clear what versions of Zope this will work with, or whether this will do the same thing as self._setObject(), it's late, I've had no sleep, I'll look later, or someone who actually knows can fill in the blanks for us, but, I think it's 2.4 only) It doesn't seem to be used by any of the Zope objects in 2.4.3 (at least not in any python ones), so it's hard to say. The ZDG does not say that self (or dispatcher as it says), will not be usable as if it was your ObjectManager. "The add function will be passed a FactoryDispatcher as its first argument which proxies the location (usually a Folder) where your product was added." This implies nothing special is needed to use the first argument as if it was the ObjectManager to which you are being installed. So from this it seems if you are running 2.4 that self should be a proxy to an ObjectManager to which you can add things w/o calling Destination() | I believe this to be the reason for issues surrounding XUF like | "undeletable" userfolders where the __allow_groups__ attribute appears to | be installed in the wrong place. err no. That was something completely unrelated, and had to do with the manage_beforeDelete() failing (now corrected). | I am not posting to the XUF list as I would have to subscribe first. Yes, we enjoy the lower spam count over on -devel, -users is open though. If you want to discuss XUF devel issues then you should subscribe and you should post there. Your patch was rejected because it claimed to fix something it was unrelated to, namely the __allow_groups__ persisting after the acl_users was deleted. Your fix could not have possibly fixed it, because the code that actually removed the attribute was never executed, which means you didn't actually test your patch against the condition you told me it was supposed to fix. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |[EMAIL PROTECTED]| _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )