ColdFusion Calendar Event Scripting - The Theory Of Handling Event Updates And Exceptions
Posted July 31, 2007 at 8:39 AM
In the previous post on ColdFusion calendar event scripting, I went over the basic architecture of adding single and repetitive events using just one database table and some clever struct-based indexing techniques for processing efficiency. Now, we are going to make the ColdFusion calendar system even more useful by allowing us to edit existing events. When it comes to editing an existing event, single-day, non-repeating events are nothing to worry about; these are basic single-record updates that 99% of our applications are composed of. Updating a repeating event is a different ball of wax altogether.
When we updated (or delete for that matter) a repeating event or "series", there are three types of updates that we can do:
- Update Entire Series
- Update Future Instances Of Series
- Update Just This Instance In Series
Like the single-event updates, updating an entire event series does not cause us any problems; we are just updating the record in the database with potentially new values. No other actions need to be taken, with the possible exception of handling existing exceptions to the given event (but we can discuss that later). This type of move can be seen in the following diagram:
| | | | ||
| |  | | ||
| | | |
Updating all future instances of a series (including the currently viewed date) is easiest to handle if we break up the existing event into two different events. The first of these two events will be the existing event with a modified end-date that falls just before the currently viewed date. The second of these two events will be a NEW event with the information the user entered. Theoretically, the new event (second event) should start where the existing event (first event) left off; however, there is nothing other than business rules that says it has to be that way.
It might be easier to think of "Future" instances of an event action as just: Truncate existing event at this point and then create a new event with user-entered details (that default to those details provided by existing event). When we look at ti this way, it's likely that our existing event and our new event will line up in some fashion, but we can see that there is nothing the must enforce this. This type of move can be seen in the following diagrams:
| | | | ||
| |  | | ||
| | | |
Updating just the currently viewed instance of an event series requires us to create a new table in the database: event_exception. This table is very simple and has just two columns:
Date - The date on which the exception occurs.
Event_ID - The foreign key to the event series in which the exception is taking place.
Like the future updates, updating just the current event instance requires us to add a new event. However, unlike the future event updates, this action does not require us to modify the existing event in any way. Instead, what we do is create an entirely new event with the user-entered data and then insert an event_exception record for the existing event series on the given day. Traditionally, the new event (current instance) is usually on the same day as the exception (with modified details), but there is nothing other than business logic that needs to enforce that. This type of move can be seen in the following diagram:
| | | | ||
| |  | | ||
| | | |
Once we have an exception in place for the given-instance update, we have to make sure not to show that event instance in the calendar. Therefore, the calendar event-populating algorithm becomes something like this:
- Check for event recurrence on given date
- Check for exception of event on given date
- If no exception,
- show event
- Else if exception
- do Not show event
Once we have exceptions in place, here is where the "best practices" become a little hairy. To be honest, I am not sure how to best handle it. My gut feeling is that exceptions should stay in the database until the originating series is deleting from the calendar system. Furthermore, I don't think that event exceptions should ever move around. Therefore, if you have a week long event that has a mid-week exception on Wednesday and then you move that entire event series to start in the next week - that Wednesday exception no longer appears in the middle of the event. This is because the exception was for the previous week, not the current week. However, if you were to then move the event series back to the original week, the exception would again present itself. This makes sense because exceptions are not really series based, they are date-based.
Now that we have examined how we are going to handle event updates and exceptions, we see that the high-level code is rather simple to update. The pseudo code for the update page looks something like this:
- If We have Existing event
- If we are updating entire series
- Then just update record
- If we are updating future series
- Then
- Put end date on existing event
- Insert new event with user-data
- Then
- If we are updating single instance
- Then
- Insert exception for existing event
- Insert new event with user-data
- Then
- If we are updating entire series
- Else
- New event series; just insert record
Not so complicated right? In fact, while this blog post is just on the "theory" of this, you can actually see this in practice already. Last night, I create a new ColdFusion calendar event system demo that allows you to edit existing events in this manner. As always, my Add / Edit screen is totally lame and not intuitive and was done quickly to examine the algorithms required and to populate the database.
Warning: The Add /Edit Event page was mad quick and dirty and might not have the best error handling. The labelling also sucks! I really just needed that page to populate a database table to test with.
As a final note, one thing we have to be careful of is that are event editing is date-specific. If we are editing a series and then make a "current instance" modification to it - we have to know the date of the current instance. To handle this, I pass in a "viewas" date to the edit page. This signifies the date-based-instance of the event we are trying to edit.
Hopefully, I will be able to clean up the code and share it with you shortly.
Comments (0) | Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Ask Ben: Finding The Last Monday Of The Month In ColdFusion
Lenny And Bo, ColdFusion Programmers (Vol. 29)
Reader Comments
There are no comments posted for this web log entry.
