Klaus, Thank you for being an alpha tester of ZScheduler. Let's carry on these discussions on zope-dev (as long as it's still an alpha product), for the benefit of other alpha testers, and to benefit from the ideas of other developers. From: "Klaus Ahrens" <ahrens@informatik.hu-berlin.de>
Loren Stafford wrote:
Here's a simple DTML method that adds a simple ZEvent. You'll have to
modify
it for your subclass and parameters.
<dtml-with "manage_addProduct['ZScheduler']"> <dtml-call expr="manage_addOneTimeZEvent( this(), 'votingEventId1', 'Voting Event Title 1', file = 'Content-Type: text/plain\n\nBANG!!!', executeAt = _.DateTime()+14 )"> </dtml-with>
-- HTH -- Loren
thank you very much for the quick response!
some details are not quite clear for me:
- i see that after calling (for testing purposes: viewing !?) such a dtml-method creates a new zevent, which when it's due does the requested action, but after that, the zevent should vanish ! but how?
As ZScheduler is currently designed, ZEvents don't automatically vanish. Past events that have not been rescheduled continue to exist and continue to be catalogued with a "null" time (DateTime(0)). I'll have to think about whether auto-deletion is an essential feature, and how it should be implemented. What do other developers think? What does 'cron' do? To delete ZEvents programmatically, you have to use the manage_delObjects method. It takes a list of object IDs as its argument. In the context of the parent folder of the events: manage_delObjects(['votingEventId1', 'votingEventId2', ...]) If all your ZEvents are in one folder you can make a list of the IDs of 'null' events thus: <dtml-call "REQUEST.set('nullZEvents',[])"> <dtml-in "objectValues(['ZEvent'])"> <dtml-if "executeAt==_.DateTime(0)"> <dtml-call "nullZEvents.append(id())"> </dtml-if> </dtml-in> <dtml-var nullZEvents> You could also use the Schedule (which is a catalog of ZEvents) to find all expired ZEvents. <dtml-in "Schedule( nextEventTime=_.DateTime(1), nextEventTime_usage='range:max' )"> <dtml-with "Schedule.getobject(data_record_id_)"> <dtml-var id> </dtml-with> </dtml-in> You could even make one of these methods a repetitive ZEvent that runs every day (or whatever interval) and removes "null" ZEvents. Would that approach suit your application? Clearly these methods are a little sketchy. You'll have to do a little DTML programming to get them to do what you want in your environment.
moreover: if there are several pending zevents they must have different id's: so i need some automatic numbering scheme for multiple zevents and some ...deleteOneTimeEvent (... ????this()???? ...) -magic as a side effect of the triggered action. i have no idea how to do that !?
You need to append some kind of "uniquifier" to the id of the ZEvent before you create it. You could create a counter property and increment it each time you use it (not recommended for frequent use). You could use some form of DateTime(). I seem to remember a discussion of this subject on zope-dev.
- one problem with DateTime which has to do with a time zone bug (i suppose) is the following: all scheduled DateTimes go off by one hour, even
_.DateTime() and _.DateTime()+0
or
_.DateTime('gmt+1') and _.DateTime('gmt+1')+0
report different times:
2000/07/31 11:16:46.517 GMT+1 (<--- now) 2000/07/31 10:16:46.5327 GMT+1
! some millis due to the execution seuqence are not the problem
i know, that has nothing to do with zscheduler but do you have any clue ?
ZScheduler depends on having a correctly-functioning DateTime module. I've been reading the discussions on zope and zope-dev lists with some consternation, but I think others have analyzed the problem thoroughly. ZScheduler's use of DateTime is very simple and straight-forward. It does not do anything to make it an more or any less vulnerable to DateTime anomalies. I can only advise that you keep "up-to-date" with the latest DateTime discussions (on both zope and zope-dev) and patches. -- HTH -- Loren