Menu
▾
▴
phpicalendar-devel — Mailing list for PHP iCalendar Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(159) |
Nov
(123) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(11) |
Mar
(21) |
Apr
(29) |
May
(13) |
Jun
(2) |
Jul
(13) |
Aug
(5) |
Sep
(14) |
Oct
(21) |
Nov
(71) |
Dec
|
| 2004 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
(6) |
May
(29) |
Jun
(9) |
Jul
(3) |
Aug
(4) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(20) |
| 2005 |
Jan
(6) |
Feb
(27) |
Mar
(4) |
Apr
(16) |
May
(61) |
Jun
(6) |
Jul
(4) |
Aug
(18) |
Sep
(19) |
Oct
(5) |
Nov
(55) |
Dec
(30) |
| 2006 |
Jan
(11) |
Feb
(9) |
Mar
(9) |
Apr
(26) |
May
(17) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(20) |
Oct
|
Nov
(6) |
Dec
(9) |
| 2007 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(8) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(17) |
Mar
(11) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chad <ch...@ch...> - 2002-11-22 06:45:11
|
Hello developers. I'm looking to get help on PHP iCalendar implementing new features, closing bugs, and trying to break PHP iCalendar (well documented). I've been working mostly on new features for 0.9 and closing bugs here and there. Jared has taken some well-deserved personal time to do the college thing. So we need your help. Some basic things to do to help: 1) Check out a current version from CVS: https://sourceforge.net/cvs/?group_id=62270 2) Find bug, fix bug. 3) Submit new feature to list, get approval, work on new feature. You can send us changes with cvs's diff function. Some may already know how this works, if not: cvs diff -u file.php >> patch.diff http://jakarta.apache.org/commons/patches.html Personally I'd like to pack as many features in 0.9 as possible, as we'll need people to really test out before 1.0. Ive already done many of these in CVS. Check the README file for changes. I'd also like to add more permanent developers to the SourceForge list. Submit us some nices patches and win us over.You'll need to butter both Jared and myself up those. -C |
|
From: Chad <ch...@ch...> - 2002-11-21 01:20:47
|
It was promptly moved to Feature Requests, as the product currently behaves as the authors have intended. It will be considered for an upcoming version. -C On Wednesday, November 20, 2002, at 04:43 PM, Greg Westin wrote: > No offense, but I think this is clearly a bug. Given valid input, the > program fails to produce acceptable output. > > Greg > > --- > gr...@gr... > http://www.gregwestin.com/ > Contact info: http://www.gregwestin.com/contact.php > > On Wed, 20 Nov 2002 no...@so... wrote: > >> Bugs item #641441, was opened at 2002-11-20 12:18 >> You can respond by visiting: >> https://sourceforge.net/tracker/ >> ?func=detail&atid=500017&aid=641441&group_id=62270 >> >> Category: Week >> Group: CVS >>> Status: Closed >>> Resolution: Rejected >> Priority: 5 >> Submitted By: Greg Westin (westin) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: overlapping events display poorly >> >> Initial Comment: >> Overlapping events mess up the columns in the week >> view. Overlapping events on Friday cause a big empty >> column after Saturday; on Sunday they cause Saturday >> to get very skinny; etc. >> >> ---------------------------------------------------------------------- >> >>> Comment By: Chad Little (clittle) >> Date: 2002-11-20 13:39 >> >> Message: >> Logged In: YES >> user_id=585637 >> >> Not a bug. >> >> ---------------------------------------------------------------------- >> >> You can respond by visiting: >> https://sourceforge.net/tracker/ >> ?func=detail&atid=500017&aid=641441&group_id=62270 >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Chad <ch...@ch...> - 2002-11-21 01:19:18
|
This bug is a duplicate of #634785 as they both have the same problem, changing of recurring events. If you wish to elaborate or present a different case of that same bug, please add it to that bug, as well as a sample calendar. I am confident that the solution for #634785 would also solve your description below. On Wednesday, November 20, 2002, at 04:50 PM, Greg Westin wrote: > Again, I don't mean to be rude, but you're wrong - or at least, you're > making an assumption that I don't think you have any support for. I > assume you're referring to bug #634785? That bug states that both the > original event and the changed event are displayed - I said that the > event > is not displayed, but there is a blank in that space as if an event > should > be there. If the old bug has now been changed to this new one, through > some work by Jared, then as much should be either listed on the > comments > for the old bug, or the old one should be replaced by the new. If > different systems or different versions of PHP iCalendar are exhibiting > different incorrect behavior in the same circumstances, then that too > should be noted. > > I apologize if I seem rude, but I'm a little annoyed by your terse > dismissal of what I think is valid input. > > Greg > > --- > gr...@gr... > http://www.gregwestin.com/ > Contact info: http://www.gregwestin.com/contact.php > > On Wed, 20 Nov 2002 no...@so... wrote: > >> Bugs item #641442, was opened at 2002-11-20 12:19 >> You can respond by visiting: >> https://sourceforge.net/tracker/ >> ?func=detail&atid=500017&aid=641442&group_id=62270 >> >> Category: Parsing iCals >> Group: CVS >>> Status: Closed >>> Resolution: Duplicate >> Priority: 5 >> Submitted By: Greg Westin (westin) >> Assigned to: Jared Wangen (jwangen) >> Summary: changed recurring event affects display >> >> Initial Comment: >> When I changed the date of an instance of a recurring >> event to a different day, both the day and week view still >> display the day it used to be on with a space where the >> event would show up. The event overlapped in time with >> another event, so before I changed the date of the event, >> they showed up skinnier than normal to fit in the >> column. However, even after moving it, the event it used >> to overlap with shows up skinny, and with the >> associated problem of all overlapping events mentioned >> in bug 641441. >> >> I can upload a calendar if this problem can't be >> replicated easily. >> >> ---------------------------------------------------------------------- >> >>> Comment By: Chad Little (clittle) >> Date: 2002-11-20 13:39 >> >> Message: >> Logged In: YES >> user_id=585637 >> >> Duplicate. >> >> ---------------------------------------------------------------------- >> >> You can respond by visiting: >> https://sourceforge.net/tracker/ >> ?func=detail&atid=500017&aid=641442&group_id=62270 >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Greg W. <gr...@gr...> - 2002-11-21 00:50:51
|
Again, I don't mean to be rude, but you're wrong - or at least, you're making an assumption that I don't think you have any support for. I assume you're referring to bug #634785? That bug states that both the original event and the changed event are displayed - I said that the event is not displayed, but there is a blank in that space as if an event should be there. If the old bug has now been changed to this new one, through some work by Jared, then as much should be either listed on the comments for the old bug, or the old one should be replaced by the new. If different systems or different versions of PHP iCalendar are exhibiting different incorrect behavior in the same circumstances, then that too should be noted. I apologize if I seem rude, but I'm a little annoyed by your terse dismissal of what I think is valid input. Greg --- gr...@gr... http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Wed, 20 Nov 2002 no...@so... wrote: > Bugs item #641442, was opened at 2002-11-20 12:19 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=500017&aid=641442&group_id=62270 > > Category: Parsing iCals > Group: CVS > >Status: Closed > >Resolution: Duplicate > Priority: 5 > Submitted By: Greg Westin (westin) > Assigned to: Jared Wangen (jwangen) > Summary: changed recurring event affects display > > Initial Comment: > When I changed the date of an instance of a recurring > event to a different day, both the day and week view still > display the day it used to be on with a space where the > event would show up. The event overlapped in time with > another event, so before I changed the date of the event, > they showed up skinnier than normal to fit in the > column. However, even after moving it, the event it used > to overlap with shows up skinny, and with the > associated problem of all overlapping events mentioned > in bug 641441. > > I can upload a calendar if this problem can't be > replicated easily. > > ---------------------------------------------------------------------- > > >Comment By: Chad Little (clittle) > Date: 2002-11-20 13:39 > > Message: > Logged In: YES > user_id=585637 > > Duplicate. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=500017&aid=641442&group_id=62270 > |
|
From: Greg W. <gr...@gr...> - 2002-11-21 00:43:17
|
No offense, but I think this is clearly a bug. Given valid input, the program fails to produce acceptable output. Greg --- gr...@gr... http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Wed, 20 Nov 2002 no...@so... wrote: > Bugs item #641441, was opened at 2002-11-20 12:18 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=500017&aid=641441&group_id=62270 > > Category: Week > Group: CVS > >Status: Closed > >Resolution: Rejected > Priority: 5 > Submitted By: Greg Westin (westin) > Assigned to: Nobody/Anonymous (nobody) > Summary: overlapping events display poorly > > Initial Comment: > Overlapping events mess up the columns in the week > view. Overlapping events on Friday cause a big empty > column after Saturday; on Sunday they cause Saturday > to get very skinny; etc. > > ---------------------------------------------------------------------- > > >Comment By: Chad Little (clittle) > Date: 2002-11-20 13:39 > > Message: > Logged In: YES > user_id=585637 > > Not a bug. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=500017&aid=641441&group_id=62270 > |
|
From: Chad <ch...@ch...> - 2002-11-20 02:34:37
|
Usually after every release I try to outline things I'd like to see in the next version. This hasn't been done for the next version mostly due to time constraints on myself and Jared. The current README lists things currently in 0.9 (in CVS). Do a checkout from CVS and test away. I'll do a roadmap tomorrow sometime, and yes, everything is up for discussion. :-) -C On Tuesday, November 19, 2002, at 06:21 PM, Cory B. wrote: > Hiya guys, > > I'm wondering if there is a developers roadmap or plan for future > releases. Is this something that is up for discussion or something that > has already been planned out? > > I'm trying to figure out what I can do to help with this project. I > have > ideas on what features I would like to have added to the project but I > want to see what is happening now before I start working. > > Also, I registered #phpicalendar on irc.openprojects.net. If anyone > wants > to chat there feel free to show up and chat... > > Peace, > > -Cory > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Cory B. <pi...@hi...> - 2002-11-20 02:26:46
|
Hiya guys, I'm wondering if there is a developers roadmap or plan for future releases. Is this something that is up for discussion or something that has already been planned out? I'm trying to figure out what I can do to help with this project. I have ideas on what features I would like to have added to the project but I want to see what is happening now before I start working. Also, I registered #phpicalendar on irc.openprojects.net. If anyone wants to chat there feel free to show up and chat... Peace, -Cory |
|
From: Jared <xe...@si...> - 2002-11-20 00:58:54
|
Ahh, I understand now. I have an idea, maybe we can let the scripts know what version it is. Then, when the data is gotten from the array, if it was created with a previous version, it will reparse to guarantee that everything is up to date. That's an easy solution and I think it will work OK. It's sort of like the "VERSION" property in the iCal spec. :) -Jared On Tuesday, November 19, 2002, at 06:00 PM, Greg Westin wrote: > Ok, I guess the problem is something that would only occur in this very > rare case. The problem I had today was that the calendar HASN'T > changed, > but what PHP iCalendar is parsing from it has, with the addition of > VTODO > support. Obviously, changes to the parser aren't common enough or huge > enough to warrant an immediate-reparsing feature, except perhaps for > developers. For some reason, I was thinking that in addition to this > problem, you'd run into trouble with changes throughout the course of a > day, because I was thinking of 'modification date' as just the date, > not > the date and the time, which of course it is. > > Sorry about the misunderstanding, > > Greg > > --- > gr...@gr... > http://www.gregwestin.com/ > Contact info: http://www.gregwestin.com/contact.php > > On Tue, 19 Nov 2002, Jared wrote: > >> On Tuesday, November 19, 2002, at 12:41 PM, Greg Westin wrote: >> >>> No, no error in that respect. I meant if people wanted the calendar, >>> in >>> general, to show the parsed calendar, but at some moment wanted to >>> get >>> the >>> most current calendar, instead. For example, if I didn't have the >>> ability >>> to change either my config.inc.php settings or remove the fiels from >>> /tmp, >>> I wouldn't be able to see my todos in any of my recently-viewed >>> calendars >>> right now, because they were parsed before I updated my CVS to >>> include >>> the >>> VTODO support. >> >> You should be able to see the changes. The script determines whether >> to >> reparse on if the file is different than the last time it parsed. If >> you added something to the file, surely the modification date would >> change and the script would know to reparse it. As Chad said, if this >> is not working for you, let me know and I'll try to figure it out. >> Providing a method to force-reparse the file would be possible (and >> easy) but I just don't see the benefit. >> >> If I'm not understanding you, please try to explain again. >> >> -Jared >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: To learn the basics of securing >> your web site with SSL, click here to get a FREE TRIAL of a Thawte >> Server Certificate: http://www.gothawte.com/rd524.html >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Greg W. <gr...@gr...> - 2002-11-20 00:00:37
|
Ok, I guess the problem is something that would only occur in this very rare case. The problem I had today was that the calendar HASN'T changed, but what PHP iCalendar is parsing from it has, with the addition of VTODO support. Obviously, changes to the parser aren't common enough or huge enough to warrant an immediate-reparsing feature, except perhaps for developers. For some reason, I was thinking that in addition to this problem, you'd run into trouble with changes throughout the course of a day, because I was thinking of 'modification date' as just the date, not the date and the time, which of course it is. Sorry about the misunderstanding, Greg --- gr...@gr... http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Tue, 19 Nov 2002, Jared wrote: > On Tuesday, November 19, 2002, at 12:41 PM, Greg Westin wrote: > > > No, no error in that respect. I meant if people wanted the calendar, > > in > > general, to show the parsed calendar, but at some moment wanted to get > > the > > most current calendar, instead. For example, if I didn't have the > > ability > > to change either my config.inc.php settings or remove the fiels from > > /tmp, > > I wouldn't be able to see my todos in any of my recently-viewed > > calendars > > right now, because they were parsed before I updated my CVS to include > > the > > VTODO support. > > You should be able to see the changes. The script determines whether to > reparse on if the file is different than the last time it parsed. If > you added something to the file, surely the modification date would > change and the script would know to reparse it. As Chad said, if this > is not working for you, let me know and I'll try to figure it out. > Providing a method to force-reparse the file would be possible (and > easy) but I just don't see the benefit. > > If I'm not understanding you, please try to explain again. > > -Jared > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: Jared <xe...@si...> - 2002-11-19 22:30:44
|
I don't know what my weekend schedule looks like but I think I'm going to be busy. My mom is having surgery so I'm going home to be with her. I might take my iBook and assuming I don't have any papers due on Monday, I should have some time to work on it. I'm sorry for not having time in the last few weeks. School has been hectic for me. I haven't abandoned the project, though. :) -Jared On Tuesday, November 19, 2002, at 11:52 AM, Chad wrote: > Is now checked in to CVS. It needs a coat of paint, but works. For 0.9 > I'll be giving PHP iCalendar a minor facelift. It is possible that we > could do a release as soon as this weekend, but I'll need help closing > out some quirky bugs. I'd like it to be SourceForge Bug Free, since > the new features will probably introduce a few new ones. > > Thanks, > Chad |
|
From: Jared <xe...@si...> - 2002-11-19 22:08:27
|
On Tuesday, November 19, 2002, at 12:41 PM, Greg Westin wrote: > No, no error in that respect. I meant if people wanted the calendar, > in > general, to show the parsed calendar, but at some moment wanted to get > the > most current calendar, instead. For example, if I didn't have the > ability > to change either my config.inc.php settings or remove the fiels from > /tmp, > I wouldn't be able to see my todos in any of my recently-viewed > calendars > right now, because they were parsed before I updated my CVS to include > the > VTODO support. You should be able to see the changes. The script determines whether to reparse on if the file is different than the last time it parsed. If you added something to the file, surely the modification date would change and the script would know to reparse it. As Chad said, if this is not working for you, let me know and I'll try to figure it out. Providing a method to force-reparse the file would be possible (and easy) but I just don't see the benefit. If I'm not understanding you, please try to explain again. -Jared |
|
From: Chad <ch...@ch...> - 2002-11-19 19:44:30
|
It's a known bug in iCal. Note that .Mac will display the event the same way as PHP iCalendar, so I'm not really interested in providing a work-around for this. -C On Tuesday, November 19, 2002, at 11:22 AM, a.h.s. boy wrote: > I just sent a note off to Apple's iCal feedback about the following, > but I don't know if you've discussed this during phpiCalendar > development. > > The COUNT parameter of the recurrence rule is, according to RFC 2445, > supposed to indicate the total number of events, including the parent > event. Apple's iCal appears to misinterpret the rule, and uses COUNT > to indicate the number of _child_ recurrences, excluding the original. > > If you create a repeating event in iCal, and specify that it repeats > daily "For 3 times", iCal produces a total of 4 events. > > phpiCalendar parses the recurrence rule and creates only 3 events. > While this is, in my opinion, the > proper interpretation, it does create a discrepancy between one's > calendar in iCal, and the phpiCalendar version...which might confuse > people. > > Cheers, > spud. > > ------------------------------------------------------------------- > a.h.s. boy > spud(at)nothingness.org "as yes is to if,love is to yes" > http://www.nothingness.org/ > ------------------------------------------------------------------- > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: a.h.s. b. <spu...@no...> - 2002-11-19 19:25:45
|
I just sent a note off to Apple's iCal feedback about the following, but I don't know if you've discussed this during phpiCalendar development. The COUNT parameter of the recurrence rule is, according to RFC 2445, supposed to indicate the total number of events, including the parent event. Apple's iCal appears to misinterpret the rule, and uses COUNT to indicate the number of _child_ recurrences, excluding the original. If you create a repeating event in iCal, and specify that it repeats daily "For 3 times", iCal produces a total of 4 events. phpiCalendar parses the recurrence rule and creates only 3 events. While this is, in my opinion, the proper interpretation, it does create a discrepancy between one's calendar in iCal, and the phpiCalendar version...which might confuse people. Cheers, spud. ------------------------------------------------------------------- a.h.s. boy spud(at)nothingness.org "as yes is to if,love is to yes" http://www.nothingness.org/ ------------------------------------------------------------------- |
|
From: Greg W. <gr...@gr...> - 2002-11-19 18:41:12
|
> Thats a bug in iCal, if you create a TODO, then delete it from iCal, it > still exists in the file. I'll probably add an option to display > completed TODO's or not, either way they will be clearly marked as such > in the list. I told yah I haven't applied the paint yet. ;-) No worries... that's interesting (but not suprising), though, about the iCal bug. I was just reading through some VTODOs to see what info they contain, and realized that it's simple to make completed todos disappear. It would also be nice to make todos with due dates coming up to go bold or something. > The script should re-parse if the file date on the calendar is > different to that of the parsed calendar. Which will happen when you > upload a new one. If its not working, let Jared know. No, no error in that respect. I meant if people wanted the calendar, in general, to show the parsed calendar, but at some moment wanted to get the most current calendar, instead. For example, if I didn't have the ability to change either my config.inc.php settings or remove the fiels from /tmp, I wouldn't be able to see my todos in any of my recently-viewed calendars right now, because they were parsed before I updated my CVS to include the VTODO support. Should I submit any of these to bugs/feature requests? Would you like help in polishing this VTODO business, or should I just wait until you come up with a version you're happy with? Greg --- gr...@gr... http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Tue, 19 Nov 2002, Chad wrote: > > -C > > > On Tuesday, November 19, 2002, at 10:14 AM, Greg Westin wrote: > > > The todo list seems to show all to-dos, even if they've been marked as > > 'done' in iCal. I hope this is one of the cosmetic changes you're > > working > > on? Also, this change reminds me of another thing I'd been thinking > > about > > - can we add an option to force the calendar to be re-parsed? Storing > > parsed calendars is great, but sometimes you want to see recent > > changes... > > > > Another cosmetic change I'd suggest for to-dos: make them an unordered > > (or > > ordered, I suppose, if there were a sensible way to order them) list, > > rather than just separated by line breaks. Otherwise, it's hard to > > differentiate between some of them. I can make this change if you'd > > like, > > but I don't know where I'd have to start in terms of vtodo parsing to > > make > > the don't-show-finished-todos change I mentioned above. > > > > Greg > > > > --- > > gr...@gr... > > http://www.gregwestin.com/ > > Contact info: http://www.gregwestin.com/contact.php > > > > On Tue, 19 Nov 2002, Chad wrote: > > > >> Is now checked in to CVS. It needs a coat of paint, but works. For 0.9 > >> I'll be giving PHP iCalendar a minor facelift. It is possible that we > >> could do a release as soon as this weekend, but I'll need help closing > >> out some quirky bugs. I'd like it to be SourceForge Bug Free, since > >> the > >> new features will probably introduce a few new ones. > >> > >> Thanks, > >> Chad > >> > >> > >> > >> ------------------------------------------------------- > >> This sf.net email is sponsored by: To learn the basics of securing > >> your web site with SSL, click here to get a FREE TRIAL of a Thawte > >> Server Certificate: http://www.gothawte.com/rd524.html > >> _______________________________________________ > >> Phpicalendar-devel mailing list > >> Php...@li... > >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > >> > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: To learn the basics of securing > > your web site with SSL, click here to get a FREE TRIAL of a Thawte > > Server Certificate: http://www.gothawte.com/rd524.html > > _______________________________________________ > > Phpicalendar-devel mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: Chad <ch...@ch...> - 2002-11-19 18:26:03
|
Thats a bug in iCal, if you create a TODO, then delete it from iCal, it still exists in the file. I'll probably add an option to display completed TODO's or not, either way they will be clearly marked as such in the list. I told yah I haven't applied the paint yet. ;-) The script should re-parse if the file date on the calendar is different to that of the parsed calendar. Which will happen when you upload a new one. If its not working, let Jared know. -C On Tuesday, November 19, 2002, at 10:14 AM, Greg Westin wrote: > The todo list seems to show all to-dos, even if they've been marked as > 'done' in iCal. I hope this is one of the cosmetic changes you're > working > on? Also, this change reminds me of another thing I'd been thinking > about > - can we add an option to force the calendar to be re-parsed? Storing > parsed calendars is great, but sometimes you want to see recent > changes... > > Another cosmetic change I'd suggest for to-dos: make them an unordered > (or > ordered, I suppose, if there were a sensible way to order them) list, > rather than just separated by line breaks. Otherwise, it's hard to > differentiate between some of them. I can make this change if you'd > like, > but I don't know where I'd have to start in terms of vtodo parsing to > make > the don't-show-finished-todos change I mentioned above. > > Greg > > --- > gr...@gr... > http://www.gregwestin.com/ > Contact info: http://www.gregwestin.com/contact.php > > On Tue, 19 Nov 2002, Chad wrote: > >> Is now checked in to CVS. It needs a coat of paint, but works. For 0.9 >> I'll be giving PHP iCalendar a minor facelift. It is possible that we >> could do a release as soon as this weekend, but I'll need help closing >> out some quirky bugs. I'd like it to be SourceForge Bug Free, since >> the >> new features will probably introduce a few new ones. >> >> Thanks, >> Chad >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: To learn the basics of securing >> your web site with SSL, click here to get a FREE TRIAL of a Thawte >> Server Certificate: http://www.gothawte.com/rd524.html >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Greg W. <gr...@gr...> - 2002-11-19 18:14:31
|
The todo list seems to show all to-dos, even if they've been marked as 'done' in iCal. I hope this is one of the cosmetic changes you're working on? Also, this change reminds me of another thing I'd been thinking about - can we add an option to force the calendar to be re-parsed? Storing parsed calendars is great, but sometimes you want to see recent changes... Another cosmetic change I'd suggest for to-dos: make them an unordered (or ordered, I suppose, if there were a sensible way to order them) list, rather than just separated by line breaks. Otherwise, it's hard to differentiate between some of them. I can make this change if you'd like, but I don't know where I'd have to start in terms of vtodo parsing to make the don't-show-finished-todos change I mentioned above. Greg --- gr...@gr... http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Tue, 19 Nov 2002, Chad wrote: > Is now checked in to CVS. It needs a coat of paint, but works. For 0.9 > I'll be giving PHP iCalendar a minor facelift. It is possible that we > could do a release as soon as this weekend, but I'll need help closing > out some quirky bugs. I'd like it to be SourceForge Bug Free, since the > new features will probably introduce a few new ones. > > Thanks, > Chad > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: Chad <ch...@ch...> - 2002-11-19 17:56:39
|
Is now checked in to CVS. It needs a coat of paint, but works. For 0.9 I'll be giving PHP iCalendar a minor facelift. It is possible that we could do a release as soon as this weekend, but I'll need help closing out some quirky bugs. I'd like it to be SourceForge Bug Free, since the new features will probably introduce a few new ones. Thanks, Chad |
|
From: Waitman C. G. <wa...@em...> - 2002-11-17 19:34:40
|
Hello
What I typically do is get rid of all "echo" and "print" commands from
the scripts, have all content producing code stuff in a string, like
$content.
I load an html layout or template into $layout. This html template has
HTML comments in it, such as
<!--Content-->
and, optional other ones such as <!--Date-->, <!--Username-->, etc.
With the layout in a single file, this makes editing the layout in
something like Dreamweaver a piece of cake.
In my script, i simply do an
$layout = @join(@file('layout.html'));
$html = ereg_replace("<!--Content-->",$content,$layout);
echo $html;
I have used this method on about 120 web sites, it works very well and
is easy to make site-wide updates.
Additionally, it makes it easy to change the content type, or send a
different layout to different browsers. (just load a different file into
$layout);
If you only have one script that does the echo $html thing, it makes
life extremely easy when managing cookies, user authentication, etc.
Additionally, you can use the mod_rewrite engine with apache to create
an instant dynamic site. Redirecting all requests to your index.php,
which reads the original requested URI and returns the appropriate
content. It can "include" content producing code on demand.
I have used the rewrite method on about 50 web sites, and it seems to
work very swell.
Take care,
Waitman Gobble
EMK Design
Buena Park, California
+1.7145222528
http://emkdesign.com
On Sun, 2002-11-17 at 10:30, Ed wrote:
I'd like to try working a template system into PHP ICalendar, in order
to improve separation of presentation and logic. There are several
options available, and I'd like to get some opinions on what folks
think would be a good choice. Here are the criteria that I had in mind
(feel free to add your own, of course):
1) Easy to integrate; preferably contained in a single file
2) Doesn't require that the file system be writable by the web server's
user (typically necessary for caching, so caching should at least be
disable-able)
3) supports some basic "if" and loop constructs, but should not be
overly complex. I have already semi-ruled out Smarty, because I think
the complexity, while powerful, is overkill. I could be convinced
otherwise, though. 8)
I tried doing some work with the PHPLIB template class. I think that
the lack of proper "if" constructs made it tedious to try and integrate
into the app as-is. I also have a very simple homegrown template
system that just uses standard PHP for logic. That would avoid having
to learn a new syntax for the templates, but it might also tempt people
to do more complex stuff than they should in the templates.
Thoughts?
--
"it's like an addiction to idiocy" -j
-Ed
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Ed <co...@fu...> - 2002-11-17 18:30:23
|
I'd like to try working a template system into PHP ICalendar, in order to improve separation of presentation and logic. There are several options available, and I'd like to get some opinions on what folks think would be a good choice. Here are the criteria that I had in mind (feel free to add your own, of course): 1) Easy to integrate; preferably contained in a single file 2) Doesn't require that the file system be writable by the web server's user (typically necessary for caching, so caching should at least be disable-able) 3) supports some basic "if" and loop constructs, but should not be overly complex. I have already semi-ruled out Smarty, because I think the complexity, while powerful, is overkill. I could be convinced otherwise, though. 8) I tried doing some work with the PHPLIB template class. I think that the lack of proper "if" constructs made it tedious to try and integrate into the app as-is. I also have a very simple homegrown template system that just uses standard PHP for logic. That would avoid having to learn a new syntax for the templates, but it might also tempt people to do more complex stuff than they should in the templates. Thoughts? -- "it's like an addiction to idiocy" -j -Ed |
|
From: Chad <ch...@ch...> - 2002-11-17 02:34:12
|
Ive gotten 4 of 5 cookies working on the preferences page. I'd like to test the code on a bunch of installs (pre 4.1.0 too) and make sure I've gotten all the kinks out. The only setting that doesn't work is '$week_start_day' which I'll need some help from Jared on. Thanks, C |
|
From: a.h.s. b. <spu...@no...> - 2002-11-16 22:46:15
|
Hey folks -- I run a PHP-based web site called the Radicalendar (http://www.radicalendar.org/), and since the release of Apple's iCal, I've been developing a new version that will enhances its compatibility with iCalendar format. (New version isn't publicly-accessible yet). Specifically, I'm 1) making it capable of output in iCalendar format, so users can "subscribe" to the various calendars, and 2) I'm using iCalendar's well-defined recurrence rules to define an interface for creating recurring events (which I didn't accommodate before). So I'm approaching iCalendar from the opposite direction of your excellent PHP iCalendar work, as I've not been concerned with _reading_ iCalendar format files. I thought we could perhaps share information or problems with each other, since I know of no other discussion lists for iCalendar (are there any? I'd love to know about them). In particular, I've run into one ambiguous situation regarding recurring events, where RFC2445 isn't clear, and Apple has chosen an interpretation that I can't find support for in the spec. To wit: If I create an event in iCal on Nov. 15th, and set it to recur DAILY every 1 DAY for 3 TIMES, iCal creates events on Nov 16, Nov 17, and Nov 18. So far so good. If I then modify (for "Only This Event") the subject of each one of the events on Nov 16,17,18, I am left with the parent event (on the 15th) and 3 _modified_ recurrence instances (which are thereafter unaffected by new changes to the parent). If I then select the parent, and change the recurrence schedule to WEEKLY, every 1 WEEK, still for 3 TIMES, iCal will add events on Nov 22, Nov 29, and Dec 6. I now have _6_ children for the parent event (3 earlier modified, 3 brand new). According to my interpretation of RFC2445, the COUNT parameter should define the TOTAL number of recurrence instances, so now we have too many events. (What "should" happen according to my understanding is that NO new events are created, despite the change in recurrence rule, because we already have 3 recurrence instances). iCal appears to understand this when, if you change the parent event's recurrence rule back to DAILY every 1 DAY for 4 TIMES, it adds only 1 new event, on the 19th, because the earlier 3 children fall on the proper days in the recurrence set. This exact situation is ambiguous in RFC2445, but did Apple intentionally make the decision to interpret it in this manner, or was this an oversight? How would you interpret the "proper" action to take, and why? Cheers, spud. ------------------------------------------------------------------- a.h.s. boy spud(at)nothingness.org "as yes is to if,love is to yes" http://www.nothingness.org/ ------------------------------------------------------------------- |
|
From: Chad L. <li...@ap...> - 2002-11-15 23:28:41
|
Yes yes, cookies for all! Actually Im working with cookies on the prefs page and committed some stuff to cvs. I was hoping someone here could check it out and possibly point out where my cookies are failing. I'm want to get the Preferences page fully working this weekend. Thanks, Chad |
|
From: Waitman C. G. <wa...@em...> - 2002-11-11 00:44:58
|
Wow, that's a great idea.
You might need a checker thingy to make sure that some numbnuckles like
me doesn't set the BASE wrong. But I do suppose since you are going to
put that thing at the top that tells the machine to use that particular
location as the current working directory, it wouldn't really matter.
Take care,
Waitman
On Sun, 2002-11-10 at 16:34, Jared wrote:
You're right that getcwd() isn't an option. That's the whole point of
BASE in the first place, to tell the scripts where the BASE PHP iCal
directory is. However, if at the top of every script, we run a function
(yet to be written) which changes the cwd to the base phpicalendar
directory, everything should work fine and we can use getcwd() to use
the full path.
My thoughts on this would be to check for the existence of a directory
called "functions," a directory called "styles," and a directory called
"languages." If these 3 are all found, we could possibly check for the
existence of "functions/ical_parser.php," If all this hold up, I think
it'd be safe to say we're in the phpicalendar root folder. A function
that does that wouldn't be hard to write. I'm just wondering if that is
sufficient enough to make an accurate assumption.
-Jared
On Sunday, November 10, 2002, at 05:06 PM, Chad wrote:
> This issue seems to have come about due to Apache 2.x and PHP4.2.x
> working together and breaking relative paths (ie ../filename instead
> of /my/path/filename). This bug was reported at php.net and can be
> seen at the urls:
>
> http://bugs.php.net/bug.php?id=19323
> http://bugs.php.net/bug.php?id=19287
>
> The suggested course of action is to upgrade your version of PHP to
> PHP4-STABLE-200210011500 or higher, or consider changing Apache back
> to the 1.3 branch.
>
>
> Unfortunately using getcwd breaks certain pages, such as the RSS index.
>
>
>
>
> On Wednesday, November 6, 2002, at 02:14 PM, Waitman C. Gobble wrote:
>
>> great.
>>
>> what do you think about changing the constant BASE to a variable, and
>> setting it to getcwd()
>>
>> ?
>>
>> there was a report of a bug in php 4.2.3 with apache 2.0.43 the messed
>> up the file_exists call. i have seen this bug in previous versions of
>> php, not sure why it has apparently resurfaced, but using the full
>> path
>> with getcwd fixes the problem.
>>
>> the change would simply prevent future incidence.
>>
>> the getcwd() should be used in a single place, with a note :
>>
>> in case some ISP has this function blocked in their php.ini
>> configuration file, the user can manually place the full path in the
>> $BASE variable and remove the getcwd() call.
>>
>> otherwise, perhaps we could check to see if the function is available
>> and default to the "./" thing.
>>
>> thanks!
>>
>> waitman
>>
>>
>> On Wed, 2002-11-06 at 11:26, Bill Fenner wrote:
>> Waitman said:
>>> i noticed a problem with
>>> http://www.emkdemo.com/phpicalendar-0.8.1/rss/index.php
>>>
>>> i was getting a "WARNING: failed to include fle ./header.inc.php on
>>> line
>>> 17" at the top of the page.
>>
>> I changed this to use BASE like the include of the footer.
>>
>> I also fixed the problem that descriptions weren't being included
>> in the rss feed.
>>
>> Bill
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: See the NEW Palm
>> Tungsten T handheld. Power & Color in a compact size!
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: See the NEW Palm
>> Tungsten T handheld. Power & Color in a compact size!
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>> _______________________________________________
>> Phpicalendar-devel mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Phpicalendar-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
|
|
From: Jared <xe...@si...> - 2002-11-11 00:34:29
|
You're right that getcwd() isn't an option. That's the whole point of BASE in the first place, to tell the scripts where the BASE PHP iCal directory is. However, if at the top of every script, we run a function (yet to be written) which changes the cwd to the base phpicalendar directory, everything should work fine and we can use getcwd() to use the full path. My thoughts on this would be to check for the existence of a directory called "functions," a directory called "styles," and a directory called "languages." If these 3 are all found, we could possibly check for the existence of "functions/ical_parser.php," If all this hold up, I think it'd be safe to say we're in the phpicalendar root folder. A function that does that wouldn't be hard to write. I'm just wondering if that is sufficient enough to make an accurate assumption. -Jared On Sunday, November 10, 2002, at 05:06 PM, Chad wrote: > This issue seems to have come about due to Apache 2.x and PHP4.2.x > working together and breaking relative paths (ie ../filename instead > of /my/path/filename). This bug was reported at php.net and can be > seen at the urls: > > http://bugs.php.net/bug.php?id=19323 > http://bugs.php.net/bug.php?id=19287 > > The suggested course of action is to upgrade your version of PHP to > PHP4-STABLE-200210011500 or higher, or consider changing Apache back > to the 1.3 branch. > > > Unfortunately using getcwd breaks certain pages, such as the RSS index. > > > > > On Wednesday, November 6, 2002, at 02:14 PM, Waitman C. Gobble wrote: > >> great. >> >> what do you think about changing the constant BASE to a variable, and >> setting it to getcwd() >> >> ? >> >> there was a report of a bug in php 4.2.3 with apache 2.0.43 the messed >> up the file_exists call. i have seen this bug in previous versions of >> php, not sure why it has apparently resurfaced, but using the full >> path >> with getcwd fixes the problem. >> >> the change would simply prevent future incidence. >> >> the getcwd() should be used in a single place, with a note : >> >> in case some ISP has this function blocked in their php.ini >> configuration file, the user can manually place the full path in the >> $BASE variable and remove the getcwd() call. >> >> otherwise, perhaps we could check to see if the function is available >> and default to the "./" thing. >> >> thanks! >> >> waitman >> >> >> On Wed, 2002-11-06 at 11:26, Bill Fenner wrote: >> Waitman said: >>> i noticed a problem with >>> http://www.emkdemo.com/phpicalendar-0.8.1/rss/index.php >>> >>> i was getting a "WARNING: failed to include fle ./header.inc.php on >>> line >>> 17" at the top of the page. >> >> I changed this to use BASE like the include of the footer. >> >> I also fixed the problem that descriptions weren't being included >> in the rss feed. >> >> Bill >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: See the NEW Palm >> Tungsten T handheld. Power & Color in a compact size! >> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Chad <ch...@ch...> - 2002-11-10 23:06:01
|
This issue seems to have come about due to Apache 2.x and PHP4.2.x working together and breaking relative paths (ie ../filename instead of /my/path/filename). This bug was reported at php.net and can be seen at the urls: http://bugs.php.net/bug.php?id=19323 http://bugs.php.net/bug.php?id=19287 The suggested course of action is to upgrade your version of PHP to PHP4-STABLE-200210011500 or higher, or consider changing Apache back to the 1.3 branch. Unfortunately using getcwd breaks certain pages, such as the RSS index. On Wednesday, November 6, 2002, at 02:14 PM, Waitman C. Gobble wrote: > great. > > what do you think about changing the constant BASE to a variable, and > setting it to getcwd() > > ? > > there was a report of a bug in php 4.2.3 with apache 2.0.43 the messed > up the file_exists call. i have seen this bug in previous versions of > php, not sure why it has apparently resurfaced, but using the full path > with getcwd fixes the problem. > > the change would simply prevent future incidence. > > the getcwd() should be used in a single place, with a note : > > in case some ISP has this function blocked in their php.ini > configuration file, the user can manually place the full path in the > $BASE variable and remove the getcwd() call. > > otherwise, perhaps we could check to see if the function is available > and default to the "./" thing. > > thanks! > > waitman > > > On Wed, 2002-11-06 at 11:26, Bill Fenner wrote: > Waitman said: >> i noticed a problem with >> http://www.emkdemo.com/phpicalendar-0.8.1/rss/index.php >> >> i was getting a "WARNING: failed to include fle ./header.inc.php on >> line >> 17" at the top of the page. > > I changed this to use BASE like the include of the footer. > > I also fixed the problem that descriptions weren't being included > in the rss feed. > > Bill > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
6 messages has been excluded from this view by a project administrator.
