[Zope-dev] Re: zscheduler question

[Loren Stafford]

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