Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is one I've thought about a bit before - though I haven't put it into practice in the real world, the elements you're working with are as follows:</p> <ul> <li>Job Description</li> <li>Recurence Pattern</li> <li>Next Scheduled Occurence</li> <li>Job/Occurence History</li> </ul> <p>So far, so easy. Those are the things that get stored in the database, the means to caclulate a "next" date based on a given date and a recurrence pattern live in your business logic.</p> <p>The key piece of information for your clients <em>in general</em> is the list of next scheduled occurences so as long as those are maintained correctly (you create a new one when you mark the current one as done) that will work. Unfortunately for scheduling purposes you probably need to be able to show the next several occurences and this is the point at which things get interesting (-: Two choices: Calculate on the fly (I think this is probably better - especially with some smart "cacheing") or precalculate which is less overall load but more data to manage and keeping it up to date is more complex (quite apart from considerations of how far ahead to create schedule entries).</p> <p>So - to answer your question - why do I think on the fly is better? Well basically because the <em>only</em> "fixed" point is the next scheduled event, you're going to want to calculate your diary forward from there based on its current value (ish) and if it changes then you need to recalculate. You can get creative in terms of preserving a list of next dates cached for a particular job to aid performance as needed, but in terms of genuinely persistent storage you're only interested in the next date.</p> <p>A couple of final thoughts - firstly if the date for an occurence is changed (as in your question) there are two options for the next date, either a) continue with the original schedule regardless of the change to (or even cancellation of - yet another challenge!) the current event or b) schedule from actual completion i.e. for some things we will want them to happen every n weeks on a given day but might need to wiggle the dates back and forth from time to time whereas for other things we want them to happen 4 weeks after the previous completion. Secondly - as prompted by Jon - you ought to look at iCal, not necessarily for implementations but certainly to help understand the elements of what might make up a calendar entry and a repeat pattern.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload