I think Matt's approach would have to be based on having specific fields for that type of entry. I believe it was you, wasn't it Joshua, who suggested 3 dropdowns...
> [number] [day of week dropdown] [datepart dropdown] > Ie: > [2] [Tuesday] [Month] [SUBMIT] ...to give some "order" to the chaos of the language to parse. That, combined with two tables: "events", which are the actual occurrences of events, whether originating as "one-time" event entries, or created dynamically...and a "description" table that specifies the parameters of the recurring events. It would seem, at this point, that using those two tables could be worked to keep record generation at a minimum, allow specific instances of recurring events to be modified without affecting other dyanamically-generated instances of the recurring event, allow recurring events to be dynamically inserted without a timespan limit, and would allow viewing of calendar events for any timespan desired. Even this approach would still have to utilize dropdown fields like you suggested to give order to those "2nd Tuesday" recurring events... Thoughts? Rick -----Original Message----- From: Joshua Miller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 2:32 PM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? Yes, that would be correct ... Agreed it's not a perfect scenario - I'm going to investigate the standards doc that was passed around for clues. If you indeed want to be able to edit any event at any point during recursion for content, then you could modify the Events Table to use a Parent/Child relationship for event modifications. You could add a field for ParentID and give it the value of the eventID for which the modification is for, but that's probably a backward way of doing things. I'm trying to grasp Matt's concept of a "pattern" field. How you would parse it actually, I understand patterns, just not how to allow for as many variables as could exist with plain English as opposed to some type of codes. Matt, if you've got any more in-depth info on how you parse a pattern like: "First Monday of January from 2003 to 2015 Except January 14 2008 which will be rescheduled to January 15 2008" then I'd appreciate a glimpse into how you're accomplishing that. Thanks, Joshua Miller Head Programmer / IT Manager Garrison Enterprises Inc. www.garrisonenterprises.net [EMAIL PROTECTED] (704) 569-9044 ext. 254 ************************************************************************ ************* Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Garrison Enterprises Inc. This e-mail is intended only for the individual or entity to which it is addressed and contains information that is private and confidential. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error please delete it immediately and advise us by return e-mail to [EMAIL PROTECTED] ************************************************************************ ************* -----Original Message----- From: Rick Faircloth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 1:43 PM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? Joshua: I see how your implementatino would work by using the following tables: (I think... ;o) Table 1 (tblEvents) - contains all event data eventID: Identity/PK field for unique id ... All other relevant event data except date ... Table 2 (tblEventDates) - contains 3 columns: edID: Identity/PK field for unique id eventID: foreign key that ties to the tblEvents entry eventDate: Date of the event If a person was inserting an "event" that was marked as recurring, then the code would process all the specific instances of the event and put the dates for the events in table 2 above as individual records for each occurence for a certain time period, say, for two years, then the other event information (all but the date) goes into a table once... Then when the calendar is pulled up, the event details and the dates of all occurences are pulled to gether and displayed. Potential problems that I see: The approach would seem to limit seeing future occurrences of an event beyond the limit set for the initial insertion. i.e., if the timespan limit for creation of specific events was the end of 2004, then recurring events for 2005 would not appear. Therefore, for anything beyond that limit, another insertion of the "recurring event" would have to be made at a later time, which would run counter to the nature of a "recurring event." Also, since the table "tblEvents" would only contain a description of "multiple" occurrences of an event, the details could not be changed for one occurrence, say, a location change, without changing all occurrences of the event. Would this be correct? Rick -----Original Message----- From: Rick Faircloth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 1:30 PM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? Trying to figure out just how your approach would be implemented... You're suggesting one table for everything? And I can't get my brain around an implementation that would handle your approach: >For example, suppose you created an implementation to support patterns >like, "the first day of every month from 1/1/97 to 1/1/98." The former >is a recurring pattern, but could easily be turned into a one time >event by thinking of it as, "the first day of every month from 1/1/91 >to 1/1/98." Wouldn't that pattern have to be turned into specific occurrences at some point? Rick -----Original Message----- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:06 PM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? For example, suppose you created an implementation to support patterns like, "the first day of every month from 1/1/97 to 1/1/98." The former is a recurring pattern, but could easily be turned into a one time event by thinking of it as, "the first day of every month from 1/1/91 to 1/1/98." While it may seem silly to describe even one time events using a similar pattern to recurring events, it does give a system a single way to deal with events, which IMHO, it enormously valuable. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Rick Faircloth [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 11:53 AM > To: CF-Talk > Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? > > Hi, Matt. > > I think Jeremy is basically taking the same approach I've been > considering: events are not actually stored as "specific occurrences" > except in the "events" table. The second table only contains > "descriptions" of recurrence patterns involving events, but not the > events themselves. > The info in the second table on serves to allow creation of events. > > When you say "a properly implemented recurring event pattern should also > support one time events" what do you mean, specifically, by "support"? > > Rick > > > -----Original Message----- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 8:47 AM > To: CF-Talk > Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? > > > I agree that you should handle recurring events by storing them as a > pattern. However, I don't agree that you should store events two > different ways depending on whether they are recurring or one time. As I > see it, a properly implemented recurring event pattern should also > support one time events. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.montarasoftware.com/ > 888-408-0900 x901 > > > -----Original Message----- > > From: Jeremy Allen [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 15, 2003 8:26 AM > > To: CF-Talk > > Subject: RE: RE: How to handle Calendar Scheduling of Recurring > Events? > > > > Hello, > > > > We have implemented a solution at elliptIQ a couple of different ways. > We > > store regular calendar events in one table, and when an event has > > recurrence data we link to another table for storing the recurrence > > data. > > > > We calculate event recurrences and only store the data describing the > > recurrence pattern. > > > > While inserting every event in a recurrence pattern certainly isn't > > cheating, it isn't robust at all. We simply could not justify the > > maintenance headaches that presents later on. It can be tempting to > > justify doing it the "easy" way when just storing a description of > > the > recurrence > > data and producing events for a range of dates can seem daunting. > > > > We have found a way (in T-SQL) to generate recurring events based on a > > simple description. Eventually we will probably move to some Java > > component to handle the recurrence patterns, but for now T-SQL > > works. The idea > is > > simple. You do a self (cross) join that produces a *huge* amount of > > results. You narrow down that huge amount of results down to your > > recurrence > rules > > for one date using gigantic a gigantic where clause. There is a lot of > > surrounding code for that, but the basic idea remains the same. It is > not > > pretty, but it worked. It should be much easier to do recurrence > patterns > > in > > a more friendly programming language like Java. > > > > (FYI: We were able to implement and support the recurrence patterns of > > calendar events almost exactly as Outlook does). > > > > > > Good Luck! > > > > Jeremy Allen > > Application Architect > > elliptIQ Inc. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
