Menu
▾
▴
phpicalendar-devel
|
From: Jim Hu <ji...@ta...> - 2006-09-07 19:56:26
|
Been a while since I've emailed the list...but I've been trying to get time to do another bug fix release and I've run into something where I could use some thoughts on how to fix it. I was working on this bug: https://sourceforge.net/tracker/? func=detail&atid=500017&aid=1554268&group_id=62270 This is a case where the problematic event is: BEGIN:VEVENT RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=TU,TH;WKST=SU DURATION:PT1H DTSTAMP:20060907T173732Z UID:F6E3F1E5-3E8D-11DB-AFA8-000D93B8CD32 SEQUENCE:7 DTSTART;TZID=America/Denver:20060907T110000 SUMMARY:tue thurs ORGANIZER;CN="scott schmitz":mailto:sc...@re... END:VEVENT The problem is that this displays the first Thurs instance correctly, but not the next Tuesday. Looking at the code for ical_parser.php, it seems to me like $count is counting the number of days, weeks, months, or years in a repeat, not the number of times the event itself is repeating. If I'm right, then I think a major change to the parser is needed. As it stands, $count shows up at the beginning of the big while loop that handles END:VEVENT in: ====== while (($next_range_time >= $start_range_time_tmp) && ($next_range_time <= $end_range_time_tmp) && ($count_to != $count)) { $func = $freq_type.'Compare'; $diff = $func(date('Ymd',$next_range_time), $start_date); if ($diff < $count) { .... ====== The $freq_type.'Compare' functions are in date_functions.php. These just return the number of days, weeks, etc. between two dates. There are a bunch of ways this can fail to work, for example, if RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=MO,TU,WE,TH,FR;WKST=SU The calendar should only show the occurrences on MO and TU...but it will show all of them in the one week. Any thoughts? Jim ===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054 |
|
From: Wesley M. <we...@we...> - 2006-09-17 02:29:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jim, I'm thinking this is a perfect cause where an OO approach might be best. Rather than trying to figure out how many times an event should repeat and on which days, maybe we should have an event structure/ object that given a date responds yes/no as it if it should be shown. I think the logic might turn out easier that way. IIRC, right now the parser looks at an event and then tries to figure out the specific times it shows up? It's been a long time since I've looked. I think it might be easier to figure out display dates given specific dates, rather than the other way around. Memoization can be used to eat a little more space in favor of avoiding duplicate computations. Do you think that might be better? Later, Wes On Sep 7, 2006, at 12:56 PM, Jim Hu wrote: > Been a while since I've emailed the list...but I've been trying to > get time to do another bug fix release and I've run into something > where I could use some thoughts on how to fix it. I was working on > this bug: > > https://sourceforge.net/tracker/? > func=detail&atid=500017&aid=1554268&group_id=62270 > > This is a case where the problematic event is: > > BEGIN:VEVENT > RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=TU,TH;WKST=SU > DURATION:PT1H > DTSTAMP:20060907T173732Z > UID:F6E3F1E5-3E8D-11DB-AFA8-000D93B8CD32 > SEQUENCE:7 > DTSTART;TZID=America/Denver:20060907T110000 > SUMMARY:tue thurs > ORGANIZER;CN="scott schmitz":mailto:sc...@re... > END:VEVENT > > The problem is that this displays the first Thurs instance correctly, > but not the next Tuesday. Looking at the code for ical_parser.php, > it seems to me like $count is counting the number of days, weeks, > months, or years in a repeat, not the number of times the event > itself is repeating. If I'm right, then I think a major change to > the parser is needed. As it stands, $count shows up at the beginning > of the big while loop that handles END:VEVENT in: > > ====== > while (($next_range_time >= $start_range_time_tmp) && > ($next_range_time <= $end_range_time_tmp) && ($count_to != $count)) { > $func = $freq_type.'Compare'; > $diff = $func(date('Ymd',$next_range_time), $start_date); > if ($diff < $count) { > .... > ====== > The $freq_type.'Compare' functions are in date_functions.php. These > just return the number of days, weeks, etc. between two dates. There > are a bunch of ways this can fail to work, for example, if > > RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=MO,TU,WE,TH,FR;WKST=SU > > The calendar should only show the occurrences on MO and TU...but it > will show all of them in the one week. Any thoughts? > > Jim > > > ===================================== > Jim Hu > Associate Professor > Dept. of Biochemistry and Biophysics > 2128 TAMU > Texas A&M Univ. > College Station, TX 77843-2128 > 979-862-4054 > > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel - -- Wesley Miaw we...@we... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFDLMXQv4agqRAk2kRAoQHAKCnrWZfRt8C2sKCWFNZEqvqzD1oeQCgmwtN /IuWAksimmcvrJxxsa0oTi0= =g2jh -----END PGP SIGNATURE----- |
|
From: Jim Hu <ji...@ta...> - 2006-09-17 20:05:27
|
Wes, I've been thinking that the next major update should be more OO, and should involve some reengineering of the parser to make it easier for new developers to understand. I confess that I get lost in it pretty easily when trying to do bug fixes. But I'm not sure exactly what the migration path should be. If we're on the same wavelength, I'm thinking that the parser would create a collection of calendar objects, where there are two classes that extend calendar_item (I'm making up names) - calendar_event and calendar_todo. This collection of events would be used instead of the master array. As the template system steps through the time interval to be drawn, it would send messages to each event/todo as appropriate: "Do you need this time slot?" If the answer is yes, then the calendar_item returns the information needed to draw that part of the calendar. Is that a correct restatement of what you're thinking? If so, then it seems like we would need to overhaul a LOT of the existing codebase. Perhaps we need to, but it's a big job IMHO. I'm wondering about an intermediate step where the parser creates the object set, which then gets used to create a master array like we use now. But this probably would degrade performance, wouldn't it? I'm also wondering about compatibility with older php versions. The OO model changed somewhat in php5, as I recall. I think some of our users are still in php4. There's backward compatibility, I believe, but it would throw away some of the OO advantages. Jim On Sep 16, 2006, at 9:29 PM, Wesley Miaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Jim, > > I'm thinking this is a perfect cause where an OO approach might be > best. Rather than trying to figure out how many times an event should > repeat and on which days, maybe we should have an event structure/ > object that given a date responds yes/no as it if it should be shown. > I think the logic might turn out easier that way. > > IIRC, right now the parser looks at an event and then tries to figure > out the specific times it shows up? It's been a long time since I've > looked. I think it might be easier to figure out display dates given > specific dates, rather than the other way around. Memoization can be > used to eat a little more space in favor of avoiding duplicate > computations. > > Do you think that might be better? > > Later, > Wes > > On Sep 7, 2006, at 12:56 PM, Jim Hu wrote: > >> Been a while since I've emailed the list...but I've been trying to >> get time to do another bug fix release and I've run into something >> where I could use some thoughts on how to fix it. I was working on >> this bug: >> >> https://sourceforge.net/tracker/? >> func=detail&atid=500017&aid=1554268&group_id=62270 >> >> This is a case where the problematic event is: >> >> BEGIN:VEVENT >> RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=TU,TH;WKST=SU >> DURATION:PT1H >> DTSTAMP:20060907T173732Z >> UID:F6E3F1E5-3E8D-11DB-AFA8-000D93B8CD32 >> SEQUENCE:7 >> DTSTART;TZID=America/Denver:20060907T110000 >> SUMMARY:tue thurs >> ORGANIZER;CN="scott schmitz":mailto:sc...@re... >> END:VEVENT >> >> The problem is that this displays the first Thurs instance correctly, >> but not the next Tuesday. Looking at the code for ical_parser.php, >> it seems to me like $count is counting the number of days, weeks, >> months, or years in a repeat, not the number of times the event >> itself is repeating. If I'm right, then I think a major change to >> the parser is needed. As it stands, $count shows up at the beginning >> of the big while loop that handles END:VEVENT in: >> >> ====== >> while (($next_range_time >= $start_range_time_tmp) && >> ($next_range_time <= $end_range_time_tmp) && ($count_to != $count)) { >> $func = $freq_type.'Compare'; >> $diff = $func(date('Ymd',$next_range_time), $start_date); >> if ($diff < $count) { >> .... >> ====== >> The $freq_type.'Compare' functions are in date_functions.php. These >> just return the number of days, weeks, etc. between two dates. There >> are a bunch of ways this can fail to work, for example, if >> >> RRULE:FREQ=WEEKLY;INTERVAL=1;COUNT=2;BYDAY=MO,TU,WE,TH,FR;WKST=SU >> >> The calendar should only show the occurrences on MO and TU...but it >> will show all of them in the one week. Any thoughts? >> >> Jim >> >> >> ===================================== >> Jim Hu >> Associate Professor >> Dept. of Biochemistry and Biophysics >> 2128 TAMU >> Texas A&M Univ. >> College Station, TX 77843-2128 >> 979-862-4054 >> >> >> >> --------------------------------------------------------------------- >> - >> --- >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > - -- > Wesley Miaw > we...@we... > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFDLMXQv4agqRAk2kRAoQHAKCnrWZfRt8C2sKCWFNZEqvqzD1oeQCgmwtN > /IuWAksimmcvrJxxsa0oTi0= > =g2jh > -----END PGP SIGNATURE----- > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jo R. <jr...@sv...> - 2006-09-18 07:20:16
|
On Sun, Sep 17, 2006 at 03:05:19PM -0500, Jim Hu wrote: > If we're on the same wavelength, I'm thinking that the parser would > create a collection of calendar objects, where there are two classes > that extend calendar_item (I'm making up names) - calendar_event and > calendar_todo. This collection of events would be used instead of > the master array. As the template system steps through the time > interval to be drawn, it would send messages to each event/todo as > appropriate: "Do you need this time slot?" If the answer is yes, > then the calendar_item returns the information needed to draw that > part of the calendar. Well, as part of the OO I would think that each of these items "has a" schedule object. That object defines the information about the schedule. This would allow a consistent interface to asking objects about their schedule. calendar_event is a calendar_item has a schedule calendar_todo is a calendar_item (optionally) has a schedule ..etc Or perhaps calendar_item has a schedule calendar_event is a calendar_item calendar_todo is a calendar_item I don't think that the latter would make the most sense, but it all depends on implementation. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X