[Zope-dev] Re: zscheduler question
Loren Stafford
lstaffor@dynalogic.com
Mon, 31 Jul 2000 10:08:14 -0700
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