Ivo van der Wijk wrote:
[snip]
> This indeed does work. The only difference is that I'm installing the hook
> in __before_publishing_traverse__, so I don't have to do any traversal
> myself.
>
> I find it a scary solution though (though not as scary as monkeypatching
> __del__), so I'm not 100% s
Shane Hathaway wrote:
>
> a __del__() method that calls your application logic. In fact, this is
> the mechanism Zope uses to make sure the database connection gets
> closed. (see ZODB/ZApplication.py.)
Ewww... ;-)
Chris - Someone got some deodorant for ZApplication?
...sure *gets ca
Ivo van der Wijk wrote:
> Hi All,
>
> I would like to do some bookkeeping *after* an object has been published,
> i.e. imagine a request is done for:
>
> /a/b/c/d
>
> 'b' is the (folderish) object that does the accounting, 'd' is the object
> to be published. I would like 'b' to examine the RES
On Mon, Apr 15, 2002 at 09:39:47AM -0600, Casey Duncan wrote:
> The request object has a hold area which keeps objects alive as long as
> the request lives. Although I have not tried it, you might be able to
> add an object to this hold area using __bobo_traverse__ defined on B.
>
> This object
On Mon, 15 Apr 2002 15:05:32 +0200, Ivo van der Wijk <[EMAIL PROTECTED]>
wrote:
>I would like to do some bookkeeping *after* an object has been published,
The transation object lets you register methods to be called on
transaction commit, abort, etc.
Toby Dickenson
[EMAIL PROTECTED]
_
The request object has a hold area which keeps objects alive as long as
the request lives. Although I have not tried it, you might be able to
add an object to this hold area using __bobo_traverse__ defined on B.
This object's class would need to have a destructor method (__del__)
defined so th