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

2002-02-02 Thread Florent Guillaume

Andrew Kenneth Milton  [EMAIL PROTECTED] wrote:
 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)

Yes, here is the idiom I now use everywhere, according to what I read
in the code and documentation:

def addFoo(dispatcher, id, REQUEST=None, **kw):
 Adds a Foo. 
ob = Foo(id)
container = dispatcher.Destination()
container._setObject(id, ob)
if REQUEST is not None:
dispatcher.manage_main(dispatcher, REQUEST)

In any case calling the first argument self is really overloading
the meaning of the word, as we are nowhere near a method here.


Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 10  http://nuxeo.com  mailto:[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 )



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

2002-02-01 Thread 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|[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 )