Erik,
I think we're seeing the same approach, basically.
Here's what I'm thinking right now.
By whatever method, create actual events in a table
for, say, up to 2 or 3 years that cover both "one-time"
and specific instances of "recurring" events.
As specific instances, all those actual event records
can be updated as needed by a user.
For dates beyond the timespan limit for creation of
actual events as table entries, fill an array with the
specific occurrences of recurring events and use that
array to display the "specific occurences." If a user
chooses to change one of those specific occurrences,
then that changed occurrence is inserted into the events
table as an actual record, thereby creating a "one-time"
event.
With this approach:
- database entries would be limited in number
(you could actually only insert instances of recurring events that were
changed,
and thereby, have only "one-time" events in the table, greatlly reducing
the number of records...)
- users could search as far into the future as they desired
- users could modify an instance of recurring events without affecting
the future dynamically generated instances of that event
This would make use of two tables...one for all "one-time" events,
and a second table to contain the "descriptions" of recurring events.
See any problems with that, anyone?
Rick
-----Original Message-----
From: erik [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 1:46 PM
To: CF-Talk
Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events?
>So that approach would actually create 3 years of specific
occurrences of
>recurring
>events in the calendar table...right? If that's true, then it
would allow
>a user to modify a specific instance of a recurring event for
>flexibility...right?
That could work too depending on the scenario or the event
itself, didn't think of that. I was thinking more along the lines
of performance issues when mentioning that - 3 years
worth of dates seems more than enough for a user to
browse through a calendar and prevents constant access
by the db for that particular event.
>
>Also, can you describe the "refresh or trigger option" a
little more? Is
>this
>for creating specific occurrences of recurring events only
when the calendar
>is called up for viewing of a previously unviewed time
period on the
>calendar?
What I was thinking of there is an event based operation of
sorts that works both ways. A calendar is just for
presentation, a trick of the users eyes of sorts. Take a
common calendar control for instance with a select for
year. You have a month with an event on say the first day of
that particular month. Since three years will be cached on
the db end you can move forward to 2004, 2005... then
when you get to 2006 - create the successive dates for just
that year only (or two, whichever). Since you have that rule
or origin stamp of sorts, you can create the dates on the fly
as needed, may be some tricky algorithmic programming
though, best wrap some of the sql logic in a stored
procedure too. Same sort of thing when going back, though
perhaps only create one years worth of dates in the lookup
table at a time (who really goes back to look at archived
events that much, anyways) Granted I'm making some
gross user assumptions here.
Erik Yowell
[EMAIL PROTECTED]
http://www.shortfusemedia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
