phpicalendar-devel — Mailing list for PHP iCalendar Developers

Re: [PHPiCalendar-DEV] Event Ids

[David F. <da...@d2...>]

this is already happening (check out latest CVS). Note, though, I'm 
still reworking the code to standardize the event/todo popups, so it 
will change again in the next few days.

Specifically, I recently changed the event popup to use date/time/uid to 
lookup the event details instead of passing all that data through the 
form. And now, I'm changing the todo popup to have the same syntax 
(using date/time/uid, although it's really just uid) instead of encoding 
all the data, and the event popup to use the same GET syntax as the todo 
popup. So, end result is they'll match up "api"-wise.

dave

Jake Stride wrote:
> Hi,
> 
> I am currently looking at putting together a patch so that the openevent 
> function passes the event id through to the event.php script as I 
> mentioned in one of my previous posts 
> (http://sourceforge.net/mailarchive/message.php?msg_id=11445870), i'm 
> just wondering what is the best way to access this in template.php 
> draw_* functions.
> 
> Thanks
> 
> Jake
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
> 

[PHPiCalendar-DEV] Event Ids

[Jake S. <ns...@us...>]

Hi,

I am currently looking at putting together a patch so that the openevent 
function passes the event id through to the event.php script as I 
mentioned in one of my previous posts 
(http://sourceforge.net/mailarchive/message.php?msg_id=11445870), i'm 
just wondering what is the best way to access this in template.php 
draw_* functions.

Thanks

Jake

[PHPiCalendar-DEV] Re: templates

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

I'm with Chad on this one.  Although PEAR libraries can be useful, I'm 
pretty sure that a lot of installations (including some of the default 
installs on Macs) still don't come with PEAR set up as the default.  It 
seems like this would make things harder for newbies and limit the 
appeal of the new version.  If there was a big benefit that would be 
one thing, but is it really needed?

Jim

Re: [PHPiCalendar-DEV] update

[Chad L. <ch...@ch...>]

I guess I don't understand why we'd switch template engines,  
confusing longtime users (and the templates they have already made),  
for minimal added benefit. I also don't know why we'd add  
dependencies into PHP iCalendar (checking for pear, etc) that could  
introduce bugs or other unknown issues.

I know there is still HTML in the template engine, and it was always  
my goal to pull it completely out, unfortunately I didn't have then  
time needed to complete that area and spent it on getting everything  
moved over.

-C


On May 21, 2005, at 5:47 PM, da...@d2... wrote:

> Hmm, okay. What can I do to convince you otherwise?  
> HTML_TEMPLATE_IT is
> veeery similar to what's already happening, but with two benefits - a
> standardized way of doing the template code, and simpler "loop"  
> support,
> which currently is done in a bunch of different ways, including  
> having the
> html included in the php code which lessens the usefulness of the
> template. If I rewrote draw_day/day.tmpl to show you the difference  
> (and
> gave you some performance numbers, which should be roughly the same or
> maybe even better)?
>
>
>> We're not really interested in a templating add-on that would require
>> PEAR or Smarty. Smarty is bloated and really overkill for the
>> project. Writing our own template engine presented a way to provide
>> the fastest method of displaying content and allowing users to tweak
>> the code with little php knowledge.
>>
>> -C
>>
>>
>> On May 21, 2005, at 11:12 AM, da...@d2... wrote:
>>
>>
>>>> David Fallon wrote:
>>>>
>>>>
>>>>> Ugh, the switch to not using forms openevent stuff was a can o'
>>>>> worms.
>>>>> This would be vastly easier if we used a real template system -
>>>>> is there
>>>>> a reason we're not using one of the template classes from PEAR?
>>>>> (http://pear.php.net/manual/en/package.html.php) I've used
>>>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost
>>>>> identical
>>>>> (in the template) to what's already there. The code syntax is
>>>>> significantly different, of course, since all the "hard work" (the
>>>>> various regexes all over the place) is abstracted out for you. :)
>>>>> While
>>>>> I should learn my lesson after diving into this rewrite, I  
>>>>> volunteer
>>>>> myself to do the switchover if I get approval. This, of course,  
>>>>> is a
>>>>> fairly serious rewrite, but continues my "less code" mantra.
>>>>>
>>>>>
>>>>
>>>> Have you had a look at smarty.php.net? We used to use
>>>> HTML_TEMPLATE_IT
>>>> but smarty has some neat features such as caching that make things
>>>> faster and other nifty features that make templating easier
>>>>
>>>>
>>>
>>> I haven't looked at it much, but I will take a closer look. In my
>>> brief 5
>>> sec. glance after your email, two concerns jumped out - the  
>>> syntax is
>>> decently different than the existing template stuff in phpicalendar
>>> (while
>>> html_template_it is almost identical), and it's not integrated into
>>> php/pear, meaning we'd have to have an additional install
>>> requirement. The
>>> second one being the bigger of the two, since I'd definitely  
>>> recommend
>>> staying away from any additional install requirements.
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>> Want to be the first software developer in space?
>>> Enter now for the Oracle Space Sweepstakes!
>>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>> _______________________________________________
>>> Phpicalendar-devel mailing list
>>> Php...@li...
>>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>>
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>

Re: [PHPiCalendar-DEV] update

[<da...@d2...>]

Hmm, okay. What can I do to convince you otherwise? HTML_TEMPLATE_IT is
veeery similar to what's already happening, but with two benefits - a
standardized way of doing the template code, and simpler "loop" support,
which currently is done in a bunch of different ways, including having the
html included in the php code which lessens the usefulness of the
template. If I rewrote draw_day/day.tmpl to show you the difference (and
gave you some performance numbers, which should be roughly the same or
maybe even better)?

> We're not really interested in a templating add-on that would require
> PEAR or Smarty. Smarty is bloated and really overkill for the
> project. Writing our own template engine presented a way to provide
> the fastest method of displaying content and allowing users to tweak
> the code with little php knowledge.
>
> -C
>
>
> On May 21, 2005, at 11:12 AM, da...@d2... wrote:
>
>>> David Fallon wrote:
>>>
>>>> Ugh, the switch to not using forms openevent stuff was a can o'
>>>> worms.
>>>> This would be vastly easier if we used a real template system -
>>>> is there
>>>> a reason we're not using one of the template classes from PEAR?
>>>> (http://pear.php.net/manual/en/package.html.php) I've used
>>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost
>>>> identical
>>>> (in the template) to what's already there. The code syntax is
>>>> significantly different, of course, since all the "hard work" (the
>>>> various regexes all over the place) is abstracted out for you. :)
>>>> While
>>>> I should learn my lesson after diving into this rewrite, I volunteer
>>>> myself to do the switchover if I get approval. This, of course, is a
>>>> fairly serious rewrite, but continues my "less code" mantra.
>>>>
>>>
>>> Have you had a look at smarty.php.net? We used to use
>>> HTML_TEMPLATE_IT
>>> but smarty has some neat features such as caching that make things
>>> faster and other nifty features that make templating easier
>>>
>>
>> I haven't looked at it much, but I will take a closer look. In my
>> brief 5
>> sec. glance after your email, two concerns jumped out - the syntax is
>> decently different than the existing template stuff in phpicalendar
>> (while
>> html_template_it is almost identical), and it's not integrated into
>> php/pear, meaning we'd have to have an additional install
>> requirement. The
>> second one being the bigger of the two, since I'd definitely recommend
>> staying away from any additional install requirements.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>

Re: [PHPiCalendar-DEV] update

[Chad L. <ch...@ch...>]

We're not really interested in a templating add-on that would require  
PEAR or Smarty. Smarty is bloated and really overkill for the  
project. Writing our own template engine presented a way to provide  
the fastest method of displaying content and allowing users to tweak  
the code with little php knowledge.

-C


On May 21, 2005, at 11:12 AM, da...@d2... wrote:

>> David Fallon wrote:
>>
>>> Ugh, the switch to not using forms openevent stuff was a can o'  
>>> worms.
>>> This would be vastly easier if we used a real template system -  
>>> is there
>>> a reason we're not using one of the template classes from PEAR?
>>> (http://pear.php.net/manual/en/package.html.php) I've used
>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost  
>>> identical
>>> (in the template) to what's already there. The code syntax is
>>> significantly different, of course, since all the "hard work" (the
>>> various regexes all over the place) is abstracted out for you. :)  
>>> While
>>> I should learn my lesson after diving into this rewrite, I volunteer
>>> myself to do the switchover if I get approval. This, of course, is a
>>> fairly serious rewrite, but continues my "less code" mantra.
>>>
>>
>> Have you had a look at smarty.php.net? We used to use  
>> HTML_TEMPLATE_IT
>> but smarty has some neat features such as caching that make things
>> faster and other nifty features that make templating easier
>>
>
> I haven't looked at it much, but I will take a closer look. In my  
> brief 5
> sec. glance after your email, two concerns jumped out - the syntax is
> decently different than the existing template stuff in phpicalendar  
> (while
> html_template_it is almost identical), and it's not integrated into
> php/pear, meaning we'd have to have an additional install  
> requirement. The
> second one being the bigger of the two, since I'd definitely recommend
> staying away from any additional install requirements.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>

Re: [PHPiCalendar-DEV] update

[<da...@d2...>]

> David Fallon wrote:
>> Ugh, the switch to not using forms openevent stuff was a can o' worms.
>> This would be vastly easier if we used a real template system - is there
>> a reason we're not using one of the template classes from PEAR?
>> (http://pear.php.net/manual/en/package.html.php) I've used
>> HTML_TEMPLATE_IT, and it works well and the syntax is almost identical
>> (in the template) to what's already there. The code syntax is
>> significantly different, of course, since all the "hard work" (the
>> various regexes all over the place) is abstracted out for you. :) While
>> I should learn my lesson after diving into this rewrite, I volunteer
>> myself to do the switchover if I get approval. This, of course, is a
>> fairly serious rewrite, but continues my "less code" mantra.
>
> Have you had a look at smarty.php.net? We used to use HTML_TEMPLATE_IT
> but smarty has some neat features such as caching that make things
> faster and other nifty features that make templating easier

I haven't looked at it much, but I will take a closer look. In my brief 5
sec. glance after your email, two concerns jumped out - the syntax is
decently different than the existing template stuff in phpicalendar (while
html_template_it is almost identical), and it's not integrated into
php/pear, meaning we'd have to have an additional install requirement. The
second one being the bigger of the two, since I'd definitely recommend
staying away from any additional install requirements.

Re: [PHPiCalendar-DEV] update

[Jake S. <ns...@us...>]

David Fallon wrote:
> Ugh, the switch to not using forms openevent stuff was a can o' worms. 
> This would be vastly easier if we used a real template system - is there 
> a reason we're not using one of the template classes from PEAR? 
> (http://pear.php.net/manual/en/package.html.php) I've used 
> HTML_TEMPLATE_IT, and it works well and the syntax is almost identical 
> (in the template) to what's already there. The code syntax is 
> significantly different, of course, since all the "hard work" (the 
> various regexes all over the place) is abstracted out for you. :) While 
> I should learn my lesson after diving into this rewrite, I volunteer 
> myself to do the switchover if I get approval. This, of course, is a 
> fairly serious rewrite, but continues my "less code" mantra.
> 
> I have probably a day or two left in the form stuff, so I should commit 
> sometime early next week, jim. Although writing this has remotivated me, 
> so I'll see if I can finish today. I then have my two bugs to fix (the 
> guaranteed-unique uids, and fixing the year render window), and I'll 
> probably stop bugfixing until people start complaining of broken things, 
> or we get a release out - the remaining stuff I'd like to do is even 
> more "not for just before release" than this stuff. So, please give me 
> some bugs to fix. :)
> 
> dave
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Have you had a look at smarty.php.net? We used to use HTML_TEMPLATE_IT 
but smarty has some neat features such as caching that make things 
faster and other nifty features that make templating easier

Jake

[PHPiCalendar-DEV] update

[David F. <da...@d2...>]

Ugh, the switch to not using forms openevent stuff was a can o' worms. 
This would be vastly easier if we used a real template system - is there 
a reason we're not using one of the template classes from PEAR? 
(http://pear.php.net/manual/en/package.html.php) I've used 
HTML_TEMPLATE_IT, and it works well and the syntax is almost identical 
(in the template) to what's already there. The code syntax is 
significantly different, of course, since all the "hard work" (the 
various regexes all over the place) is abstracted out for you. :) While 
I should learn my lesson after diving into this rewrite, I volunteer 
myself to do the switchover if I get approval. This, of course, is a 
fairly serious rewrite, but continues my "less code" mantra.

I have probably a day or two left in the form stuff, so I should commit 
sometime early next week, jim. Although writing this has remotivated me, 
so I'll see if I can finish today. I then have my two bugs to fix (the 
guaranteed-unique uids, and fixing the year render window), and I'll 
probably stop bugfixing until people start complaining of broken things, 
or we get a release out - the remaining stuff I'd like to do is even 
more "not for just before release" than this stuff. So, please give me 
some bugs to fix. :)

dave

[PHPiCalendar-DEV] Re: validating $_POST and $_GET values

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

OK, I'll wait.  I'll move on to other parts of my site.

Jim

On May 16, 2005, at 10:13 PM, 
php...@li... wrote:
<snip>
> Message: 5
> Date: Mon, 16 May 2005 17:51:15 -0700
> From: David Fallon <da...@d2...>
> To: php...@li...
> Subject: Re: [PHPiCalendar-DEV] validating $_POST and $_GET values
> Reply-To: php...@li...
>
> note if you're doing this (good idea, btw), I should finish the
> openevent cleanup to just be a url instead of the form stuff. Let me
> know before hand, I need a day or so to finish that.
>
> Jim Hu wrote:
>> As part of an overall security sweep on my server, I'm thinking of
>> modifying my copy of phpicalendar to test the values of all
>> user-supplied variables.  I think this would involve rewriting
>> init.inc.php (that's what always get's executed first, right?  I would
>> use the general approach described in
>>
>> http://phpsec.org/projects/guide/1.html#1.1
>>
>> where the tested variables from $_REQUEST[$key] get put into an array
>> called $clean['$key'], which replaces $_POST, $_GET, or $_REQUEST 
>> where
>> appropriate.  This would mean modifying not only init.inc.php, but 
>> also
>> all files that use superglobals directly.
>>
>> I don't actually think there are currently security exploits for
>> phpicalendar, and I'm not sure how anyone would create one, but I've
>> been feeling paranoid, and I've been doing this for all my other code.
>> Any thoughts?  Is there are reason not to do this?  It will not be
>> compatible with versions of php prior to 4.1.0.
>>
>> Jim Hu
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>>
>
>
>
> --__--__--
>
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
> End of Phpicalendar-devel Digest

Re: [PHPiCalendar-DEV] validating $_POST and $_GET values

[David F. <da...@d2...>]

note if you're doing this (good idea, btw), I should finish the 
openevent cleanup to just be a url instead of the form stuff. Let me 
know before hand, I need a day or so to finish that.

Jim Hu wrote:
> As part of an overall security sweep on my server, I'm thinking of 
> modifying my copy of phpicalendar to test the values of all 
> user-supplied variables.  I think this would involve rewriting 
> init.inc.php (that's what always get's executed first, right?  I would 
> use the general approach described in
> 
> http://phpsec.org/projects/guide/1.html#1.1
> 
> where the tested variables from $_REQUEST[$key] get put into an array 
> called $clean['$key'], which replaces $_POST, $_GET, or $_REQUEST where 
> appropriate.  This would mean modifying not only init.inc.php, but also 
> all files that use superglobals directly.
> 
> I don't actually think there are currently security exploits for 
> phpicalendar, and I'm not sure how anyone would create one, but I've 
> been feeling paranoid, and I've been doing this for all my other code.  
> Any thoughts?  Is there are reason not to do this?  It will not be 
> compatible with versions of php prior to 4.1.0.
> 
> Jim Hu
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
> 

[PHPiCalendar-DEV] validating $_POST and $_GET values

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

As part of an overall security sweep on my server, I'm thinking of 
modifying my copy of phpicalendar to test the values of all 
user-supplied variables.  I think this would involve rewriting 
init.inc.php (that's what always get's executed first, right?  I would 
use the general approach described in

http://phpsec.org/projects/guide/1.html#1.1

where the tested variables from $_REQUEST[$key] get put into an array 
called $clean['$key'], which replaces $_POST, $_GET, or $_REQUEST where 
appropriate.  This would mean modifying not only init.inc.php, but also 
all files that use superglobals directly.

I don't actually think there are currently security exploits for 
phpicalendar, and I'm not sure how anyone would create one, but I've 
been feeling paranoid, and I've been doing this for all my other code.  
Any thoughts?  Is there are reason not to do this?  It will not be 
compatible with versions of php prior to 4.1.0.

Jim Hu

[PHPiCalendar-DEV] Documentation site

[Chad L. <ch...@ch...>]

The site is slowing coming back up, I've gotten the documentation  
wiki back up and updated to the lastest version:

http://phpicalendar.net/documentation/

Will keep working on the rest of the site over the next week.

-Chad

[PHPiCalendar-DEV] bug update

[David F. <da...@d2...>]

1190302 - relatively easy fix, just want to make sure we're fixing this 
"right". Asked for a sample ics file, and to see what kind of program 
creates attendees like this. Is this part of the calendar spec?

1064410 - fixed in cvs.

1046864 - fixed in cvs.

1042019 - attached a patch for this, not 100% sure since I don't use rss 
stuff much. jim, can you take a look at this?

1027631 - I'll put a patch in to fix this shortly. although this is 
tough to fix, 'cause I dont' know why the importer split up was made. Is 
someone using this, and can give me some test cases or try stuff out, so 
I know if/when I break things?

1023229 - fixed in cvs.

1017270 - fixed in cvs.

990584 - not sure what to do here, only half-or-so of the language files 
are switched to the new format. I can switch things over to the new 
format, but it'd be a tedious pain. :) But, if that's the right thing, 
let me know. I'd rather wait for people to submit the new correct 
translations, and maybe add a big comment at the top of the languages 
that aren't in the new format, "This language isn't actually working".

987743
961091 - both of these are against 1.0, and seem to no longer be valid - 
I'd recommend closing them out, and waiting for new bugs if they're 
still there.

[PHPiCalendar-DEV] big patches landed

[David F. <da...@d2...>]

I committed my three pending patches today:

* The overlapping_functions rewrite. Please let me know if there's any 
overlap weirdness now in day/week.php, "every" case should now work.

* The openevent cleanup. I still should finish this off, by either 
switching the todo to match, or (the right way, presuming there's not 
some other weirdness I don't know about), remove the submit via post 
stuff and switch the todo calls over as well.

* The bleed_time fix, so bleed_time now defaults to "off" (-1) instead 
of $day_start.

Most of the bugs on sf are fixed - I'm going to go through them all 
again later today and either fix, or post why we should close, but we 
should be "bug-free" by the end of the day. Let me know what's next - I 
can keep going through patches/RFEs, and start on my own cleanups, but I 
didn't want to get too far into that before we released 2.0.

dave

[PHPiCalendar-DEV] rss.php updated

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

The rss.php still needs to be cleansed of some of the weird things I 
added, but in the meantime, I fixed a really stupid bug I introduced - 
the previous version didn't handle data ranges that crossed into the 
new year properly.  I also did a kludge to handle "&" symbols causing 
nonvalidation of the feed.

Jim Hu

[PHPiCalendar-DEV] Two bugs I need to fix

[<da...@d2...>]

This is a reminder about two bugs I need to fix (so I don't forget, and in
case I get hit by a bus, other folk are aware)

* $uid definitely needs to be unique, or things get hosed - this is a
simple fix to ical_parser, where if we find a duplicate key, we append
"-2", "-3", etc. to the end until we find a unique key. When/if we do
editing, we'll need a way of finding out the true key.

* Due to the way the range of generated events is created, when doing year
view, it doesn't render out all the events, just the events a month or two
either way. This looks correct if you set $save_parsed_cals to yes, since
it sets up a wider render window by default. year.php should modify the
render window to at least cover the entire year displayed. Should probably
also make sure the rss year feed works.

Re: [PHPiCalendar-DEV] overlapping events bugs

[<da...@d2...>]

> Sorry Ive been preoccupied with another project. It might be a good
> time to note that when fixing bugs, to check that the calendar itself
> is properly written against IETF-2445. Most times iCal/Mozilla/
> Sunbird files are ok... and generally we dont accept hand written
> ical files.

Yup - the calendar files w/ that bug are correct, and render fine once the
overlap code is working properly. So, a quick status report on that - I
finished the rewrite yesterday, and spent most of the day testing. While
this is a bogus situation - rewriting a piece like this from scratch when
we're trying to stabilize - please believe me that I spent 2 days trying
to shoehorn the "right" way into the existing code, and kept running into
fundamental flaws in how it worked. I then gave up, spend the next 2 days
rewriting everything from scratch, and then spent today testing. If it's
worth it, I'd be happy to go into more technical detail why there were
things that just wouldn't work properly using the existing logic, and how
my rewrite should be more foolproof.

I've also tried to make the code as low-impact as possible - I've only
reworked the overlap code, and it seems to work fine in all the trivial
cases, so worst case, we'll find some bugs in the already-messed-up edge
cases (which I will promptly fix, now understanding the code). As an added
benefit, the code is cleaned up, semi-faster (it's probably about the same
or even slower, actually, because it's much more rigorous in generating
correct overlap_arrays, but the base-cases should be faster), and more
modular. And now should work regardless of the craziness of your overlap
setup.

So, here's my proposal - I'd like to commit this, my openevent cleanup
patch, and then finish going through the remaining bugs (I think there's
only one or two more relevant ones). Once that's done, we should release a
2.0b2, wait a week or 2, and release 2.0. :) Hopefully w/ website at the
same time. So, barring any complaints, I'll commit my code next week (with
suitable announcements, etc.) - all you loyal readers, please try CVS at
that point and let me know if you run into anything! I will fix it if I
know about it.

> It might also be good that we have a regression suite of test
> calendars for when we test any major code changes. The checkOverlap
> function was written by David Reindl who may be able to help you fix
> anything, although that function has been very stable over the past
> few years to my knowledge.

Yeah, a regression test suite would be interesting - we could hack
something up that wget'd specific calendar+date+page combos, then compared
that to the "known good" render. Would help with the testing a lot, esp.
with some of the overlap issues (you get fun problems depending on the
order you load the calendars, as the various events create new overlap
blocks and/or merge the blocks). I'll take a look at setting something up
next week, as well.

dave

Re: [PHPiCalendar-DEV] overlapping events bugs

[Chad L. <ch...@ch...>]

Sorry Ive been preoccupied with another project. It might be a good  
time to note that when fixing bugs, to check that the calendar itself  
is properly written against IETF-2445. Most times iCal/Mozilla/ 
Sunbird files are ok... and generally we dont accept hand written  
ical files.

It might also be good that we have a regression suite of test  
calendars for when we test any major code changes. The checkOverlap  
function was written by David Reindl who may be able to help you fix  
anything, although that function has been very stable over the past  
few years to my knowledge.

-C

On May 11, 2005, at 10:43 AM, David Fallon wrote:


> I've gone quiet over the past few days because the overlapping  
> functions has been kicking my ass. Every time I successfully fixed  
> one problem, another one popped out of the woodwork. So, I'm going  
> to take a step back and redo the code (since all the problems are  
> in checkOverlap). This is a semi-crappy solution, as I could very  
> well introduce new problems, but I guarantee we'll at least get  
> full coverage (and I'll be better equipped to fix bugs as people  
> report them, instead of my struggles to keeps shoehorning fixes  
> into the existing structure). If you'd like to see the calendars  
> i'm wrestling with, check out SF Bug #1017270. Overlapping info  
> gets messed up depending on the weird overlappings setup, and this  
> calendar (check out the week of 20040829, esp the end of the week,  
> and when combined w/ Home.ics) has all kinds of weird overlapping  
> going on. :) Still waiting to hear on all my other patches.
>
> dave
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>

[PHPiCalendar-DEV] overlapping events bugs

[David F. <da...@d2...>]

I've gone quiet over the past few days because the overlapping functions 
has been kicking my ass. Every time I successfully fixed one problem, 
another one popped out of the woodwork. So, I'm going to take a step 
back and redo the code (since all the problems are in checkOverlap). 
This is a semi-crappy solution, as I could very well introduce new 
problems, but I guarantee we'll at least get full coverage (and I'll be 
better equipped to fix bugs as people report them, instead of my 
struggles to keeps shoehorning fixes into the existing structure). If 
you'd like to see the calendars i'm wrestling with, check out SF Bug 
#1017270. Overlapping info gets messed up depending on the weird 
overlappings setup, and this calendar (check out the week of 20040829, 
esp the end of the week, and when combined w/ Home.ics) has all kinds of 
weird overlapping going on. :) Still waiting to hear on all my other 
patches.

dave

[PHPiCalendar-DEV] Fix for a sf bug that should get wider testing

[David F. <da...@d2...>]

I just committed code to fix SF Bug #1023229. The long explanation is I 
changed how the weekly recurrence rendering was working to be more 
accurate (basically the same fix I did for the yearly rendering - 
obviously, I'll take a look at the monthly rendering next).

The way the weekly recurrence rendering was working (and this applied to 
all the rendering, was starting w/ the begin date, and until the 
end/until date, it would render from the sunday before the begin date to 
the sat after the begin date (the week of the begin date), the skip 
forward $interval weeks and render out that week, until it reached the 
end date. The problem was when begin_date was a later day in the week 
than until (and there was a Byday that mattered for the until) - the 
"rendering window" would miss the last day, since it didn't match the 
actual date range. So, the code would do this:

for a weekly event, every tuesday & thursday, from 05/05 (thurs) until 
05/17 (tues) -
start on TH (05/05), render out from SU (05/01) - SA (05/07). This gave 
you 05/03 and 05/05 - incorrect, but the extra date got thrown out at a 
later check, so it wasn't a big deal.
Skip ahead a week, and render the next week - TH, 05/12. This rendered 
from SU - SA, 05/08-05/14, and added 05/10 and 05/12. Check, what we wanted.
Skip ahead a week and stop rendering, 05/19 is past our end date of 05/17.

And thus, the last day was lost. I fixed this by having the rendering 
window be from begin_date to begin_date + interval weeks, i.e., in the 
above example, 05/05 - 05/11, TH - WE for the first week. The other 
rendering bug I fixed earlier was the same issue for years (it had the 
rendering window as 01/01-12/31, instead of begin_date - begin_date + 1 
year, so the same problem where things were dropped occurred.

The short answer is while I know this fixes the problem, and seems to be 
fine with all the calendars I tested, the weekly recurrence may not be 
100% correct yet because there may be edge cases I missed. Please try 
out CVS, let me know. Once we've worked through all the outstanding 
bugs/patches, I'd recommend a 2.0 beta 2, to make sure everything's 
still okay.

dave

Re: [PHPiCalendar-DEV] code cleanup patch - more fixes

[<da...@d2...>]

> David Fallon wrote:
>
>> 3. I noticed a two  issues with the generation of master_array -
>> first, the recur data wasn't being replicated to each instance of the
>> event, only the first event - so (without iterating through the whole
>> array) there was no good way to get it. So, I fixed that. This raises
>> the size of master_array by a decent amount, so it's questionable, but
>> necessary for me to implement recur details in the event popup.
>
> Ah, that could be really good! I've not been developing phpicalendar but
> I have been using the object the parser generates in conjunction with  a
> modified version of Jim Hu's script which turns it into RSS. I then in
> turn use the customised RSS feed in conjunction with MagpieRSS to
> generate a page of events
> (http://www.catmosearts.co.uk/calendar/events.php).
>
> One problem I came across was that for recurring events, if the RSS feed
> started in the middle of a recurring event, the data regarding the
> recurrence was lost as it only appears in the original occurrence. The
> only way I got round it was a dirty hack which grabs the data from 6
> months in the past to make sure the recurrence data is grabbed. This
> has an obvious flaw but works for my specific needs.
>
> The one thing that I changed in phpicalendar ical parser was to supress
> the formatting of the until date (localizeDate($dateFormat_week,$until)
> I think) because the until date was in a useless format (for my needs)
> and it was more useful for me as a unixtime. This of course meant a
> separate parser for phpicalendar and the rss generator.
>
> Thanks for your work!

Well, it's not in CVS yet, but hopefully this will be more motivation for
someone to sign off on it. :)

If it doesn't make it into 2.0, let me know and I can give you a patch
that does it (it's a fairly small change).

dave

Re: [PHPiCalendar-DEV] code cleanup patch - more fixes

[Ben F. <li...@hi...>]

David Fallon wrote:

> 3. I noticed a two  issues with the generation of master_array - 
> first, the recur data wasn't being replicated to each instance of the 
> event, only the first event - so (without iterating through the whole 
> array) there was no good way to get it. So, I fixed that. This raises 
> the size of master_array by a decent amount, so it's questionable, but 
> necessary for me to implement recur details in the event popup. 

Ah, that could be really good! I've not been developing phpicalendar but 
I have been using the object the parser generates in conjunction with  a 
modified version of Jim Hu's script which turns it into RSS. I then in 
turn use the customised RSS feed in conjunction with MagpieRSS to 
generate a page of events 
(http://www.catmosearts.co.uk/calendar/events.php).

One problem I came across was that for recurring events, if the RSS feed 
started in the middle of a recurring event, the data regarding the 
recurrence was lost as it only appears in the original occurrence. The 
only way I got round it was a dirty hack which grabs the data from 6 
months in the past to make sure the recurrence data is grabbed. This  
has an obvious flaw but works for my specific needs.

The one thing that I changed in phpicalendar ical parser was to supress 
the formatting of the until date (localizeDate($dateFormat_week,$until) 
I think) because the until date was in a useless format (for my needs) 
and it was more useful for me as a unixtime. This of course meant a 
separate parser for phpicalendar and the rss generator.

Thanks for your work!

-- 
Ben "tola" Francis            http://hippygeek.co.uk
----------------------------------------------------
COMPUTER SUPPORT for small businesses and home users
http://tolatech.co.uk
----------------------------------------------------

[PHPiCalendar-DEV] more fixes/patches went in

[David F. <da...@d2...>]

A bunch more minor patches went in:

1177367 - applied
1162488 - was already fixed
1093772 - applied
1059866 - applied
1047465 - applied
1043823 - applied, release README should be updated.

some questions/comments:
1104356 - seems worth doing before 2.0, but wanted someone to okay it.
1059794 - I was looking at this one, and got sucked into the seeming 
redundancy of publish.ical.php vs. publish.mozilla.php. After cleaning 
them up, the diff leaves some very minor differences. Anyone know why 
they were split?
1040673 - Seemed like you didn't want to apply this one pre-2.0, so I 
held off.

resolved bugs:

1046864
1064410

dave

[PHPiCalendar-DEV] fixed a bug, need someone/permissions to close

[David F. <da...@d2...>]

I fixed SF bug #1064410, but I don't seem to have permissions to close - 
can someone close or give me the ability?

I also committed my month_link.patch, as it's a very small feature (and 
no one should be negatively affected by it).

Patches that still need review:

bleed_time.patch - the fix for the bleed_time rendering issues jamin 
mentioned.

openevent.patch - the cleanup of the openevent code. Note that if this 
is good, I should "finish" this cleanup by changing the todo stuff to 
match. And part b of finishing it is if after the cleanup, I can remove 
the hidden form submit stuff, which would further reduce the code/html 
sizes.

I'm going to keep looking at bugs to help get 2.0 out the door, so I can 
start getting my features in - so if there are other bugs you know 
about, please let me know so I can fix!

dave