The problem noted below with the Trigger tab occurs only when Zope is limited to a single thread. The problem is due to contention for the single thread. The workaround is to avoid using the Trigger tab on single threaded Zope's. Or change ZEvent.py like this: def manage_triggerZEvent(self, client=None, REQUEST=None, RESPONSE=None, **kw): """For use by the Trigger tab on ZEvent management page. Use for testing the ZEvent in a context that mimics that of Dispatcher. """ aurl=REQUEST['URL1'] furl=string.join((aurl, 'trigger'), '/') RESPONSE.redirect(furl) With this fix, the product is fully functional, as far as I know, tho it remains an alpha product simply because it hasn't received a thorough shakedown. I'll have a new release out soon with this fix and other changes. -- Loren
ZScheduler Version 0.0.7 Date: 2000/07/02
1. Fixed a bug that caused ZEvents to execute in the wrong context.
2. If the action method of a ZEvent raises an error, a traceback is written in the log.
3. Added a Trigger tab to the management screen for ZEvents which fires the event in the same context that the Dispatcher does, but without regard to the schedule. This helps immensely in debugging the DTML in the ZEvent.
I've tested on: Win98 Zope 2.2.0b3 Solaris 2.6 Zope 2.1.4 Linux ?.? Zope 2.1.3
On the Linux configuration (my account at CodeIt Computing), most features work; however, the new Trigger tab does not behave correctly. Though the ZEvent method eventually executes correctly, it doesn't return anything to the client and Zope seems to lock up temporarily -- that is, it doesn't respond to other client requests. I don't have a Linux development system with which to track this down. Any help would be appreciated.
[...snip...]
Otherwise, ZScheduler is looking good. Let me know how it works for you.
http://www.zope.org/Members/lstaffor/ZScheduler
-- Thanks -- Loren