[Zope-dev] Re: self = self.this() in Factory Methods [Was: Dynpersist.so and makefile.pre.in]

[Andrew Kenneth Milton]

+-------[ 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    |akm@theinternet.com.au|