Re: [PHPiCalendar-DEV] Emailing events proof of concept

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

We've moved to just passing a serialized array for the popup 
information, that way just one field can contain all the information. 
This is already in practice I believe with the TODO popup. The 
master_array does have some performance issues, Jared and I have gone a 
long ways to speed things up but we probably won't look at the issue 
again until we stop adding new code to it (for better calendar 
support). Using UIDs to speed up might work, but I wonder what the cost 
is to search the array vs. writing it. Also, as it is now, they are 
nicely separated and anyone can build their own displayer. Using UID 
makes this slightly more difficult.

Hover events are cute but of no real practical use(IMHO). No one knows 
or expects them to be there and they can really drag in slow 
browsers.This could make for a nifty Mod though.

My idea for 'Email this event' was this:
A field and email button at the bottom of the todo or event popups. The 
email mechanism you've built looks like  its working pretty well, you 
could simply move all the code to an 'email.inc.php' file that we can 
include anyplace. Bill your emails look nice, just needs a coat of 
paint which I can do if needed.

-C


On Sunday, December 1, 2002, at 02:15  PM, Jon C. Thomason wrote:

> I've given some thought to that issue, myself.  I think it would speed 
> up display times for users on a slow link.
>
> My main events calendar features a weekly repeating event with a 
> fairly lengthy description.  With things implemented as they are, that 
> one description is included up to ten times in the output of 
> month.php!  Once for each week it appears in the month view, and then 
> once again for each time it appears in the list of events at the 
> bottom.  Thank goodness it's not a daily repeating event.  :)
>
> So replacing those ten instances of description text with UIDs would 
> help a lot.  Especially since they delay the drawing of the main page 
> table, without contributing to its appearance.
>
> Incidentally, this would also solve a problem we encountered with CGI 
> deployments of PHP.  Event descriptions can't contain slashes, or PHP 
> will fail to load and the pop-ups will come up blank.  Our workaround 
> for now is to escape %2F with %1B.
>
> On the other hand, constructing the master_array is quite a lot of 
> start-up cost.  Arguably too much for just a single pop-up event 
> description.  Especially if the source calendar (or calendars!) are 
> located on a remote server.  The difference in load times would need 
> to be regained by good caching.  Or at least by having an optimized 
> path to look up a single event's description from a single calendar 
> file.
>
> Even if the decision is made to keep event descriptions in the code of 
> the main page, we can still reduce the duplication, and improve the 
> page display times:
>
> Add each description to an associative array based on UID.  Then 
> construct one JavaScript function at the end of the file (after the 
> main tables are closed).  That function would define the associative 
> array and its contents, look up the event description based on the 
> UID, and perform the pop-up there.
>
> That way repeating event descriptions would only appear once in the 
> file, and a browser would be able to draw the visible table even while 
> the as-yet invisible descriptions are still loading.
>
> The same associative array in JavaScript could eventually be used with 
> the DOM to show event descriptions as hover effects.  That wouldn't be 
> possible if we moved them entirely into event.php.
>
> On Sunday, December 1, 2002, at 03:54  PM, Bill Fenner wrote:
>
>> What I'd like to do is to change event.php so that instead of being
>> told all the useful info about the event, it gets passed the calendar,
>> date, time and uid -- that way it can grab the right stuff out of
>> the master_array to display, plus it can know those bits to pass them
>> along to email.php so there can be an "email this event" link from
>> the event.php popup .
>
>
>
> -------------------------------------------------------
> 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