[PHPiCalendar-DEV] Re: code cleanup patch

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

I think we need Chad to weigh in before changing how the master array 
handles repeating events...what happens to the size of the array if the 
event is set to repeat forever?

Jim Hu

On May 3, 2005, at 7:47 PM, 
php...@li... wrote:
<snip>
> Message: 2
> Date: Tue, 03 May 2005 16:29:54 -0700
> From: David Fallon <da...@d2...>
> To: php...@li...
> CC: ji...@ta...
> Subject: Re: [PHPiCalendar-DEV] code cleanup patch - more fixes
> Reply-To: php...@li...
>
> This is a multi-part message in MIME format.
> --------------080707090207070601060108
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> So, this is worth applying, but only if you don't apply my forthcoming
> patch - I'll shortly (maybe later today) have a reworked
> openevent/event.php setup that uses date+time+uid to lookup the event,
> instead of passing the data to the page. This leads to a few questions:
>
> 1. is this acceptable? I'm kinda running wild here since no one's 
> saying
> anything, but obviously I'd like to run wild in the right direction.
>
> 2. if the patch goes in, it's significantly less data to pass through -
> which means we could remove the "changing the hidden form" hackery? If
> so, let me know, I'll put together a patch.
>
> 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. Second, all-day
> recurring events after the first one weren't getting set with valid 
> uids
> - they were being added to the allday time w/ the "next" array key,
> instead of using the uid. This is less questionable, and a one-line fix
> - both fixes are in the patch, but if you want to cherry pick and would
> prefer this fix alone, let me know.
>
> So everyone knows, my immediate goals are:
>
> * adding recur info to the event.php popup, so it's more useful, and so
> I learn enough to do:
>
> * add basic event adding/editing. This obviously assumes that the
> phpicalendar "owns" the calendar, and thus will ignore locking/sync'ing
> beyond making sure it doesn't overwrite itself. This will be entirely
> optional (I'm happy to make it some sort of config option people have 
> to
> turn on in general or per-calendar).
>
> * And then probably add a basic level of user support, so users can 
> have
> their own calendars vs. shared calendars, etc. Simplistic calendar 
> server.
>
> As always, I'd much prefer to do this the "right" way, in that
> maintaining a patch set against CVS sucks long term - so if there are
> way you'd prefer this done, please let me know and spare me the time
> reworking things later. phpicalendar has a *@(#ing awesome interface, 
> by
> far the best I've seen so far, and the last piece I need to solve a few
> problems for me is the editing.
>
> (cc'd jim so you get the patch)
>
> dave
> <snip>