Re: [PHPiCalendar-DEV] COUNT

[Jim Hu <ji...@ta...>]

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