phpicalendar-devel

[PHPiCalendar-DEV] Emailing events proof of concept

[Bill F. <fe...@re...>]

Check out

http://irg.attlabs.net/~fenner/test/phpicalendar/email.php?cal=School&date=20021202&time=1030&uid=3805D39E-F1C7-11D6-A283-0050E4E60429

Since I am a programmer and not a web designer, it looks pretty awful,
but it tries to pick out the right bits of the ical source file to send
via email to the email address of your choice.  That's a sample event;
the 3 arguments are the 3 indexes to master_array[].  You should be able
to select any event from any of the sample calendars with the right
3 arguments.  Normal events work, todos don't work yet.

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 would change, e.g.

href="javascript:openEventInfo('First%2BAid%2B%2526%2BCPR', 'School', '10:30 AM', '11:30 AM', '')"

to

href="javascript:openEventInfo('School','20021202','1030','3805D39E-F1C7-11D6-A283-0050E4E60429')"

and event.php would return the right values from $master_array
instead of just returning what it was passed in.

What do you think?

  Bill

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

[Jon C. T. <cal...@wa...>]

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 .

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

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

[blaine <la...@us...>]

On Sunday, Dec 1, 2002, at 15:40 America/Vancouver, Chad wrote:

> 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.

Perhaps for version 1.0 or 1.1 some sort of squirrelmail-like plugin 
system (in conjunction with templates) could make it very easy to add 
this sort of thing. Just a little hook, and you can do all sorts of 
fancy things.

> 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.

One feature I'd really like to see along with this would be support for 
periodic emails; it would require cron, of course, but it would be 
great to be able to send calendar updates at regular intervals, so that 
people don't need to go to the website (or subscribe to an rss feed) to 
get calendars.

Something to go along with this (and the RSS feeds) is recently added 
or changed events. This could be done with the Last-Modified and 
Created property, in conjunction with Sequence. As I envision it (and 
this might not be to spec, but the rfc isn't very clear on this point), 
sequence would only be incremented for significant changes to the 
event; that way, people wouldn't be notified if a spelling mistake was 
fixed, etc. The RSS feed could be called with a "new events since..." 
parameter, with the default set in config.inc.php. Likewise, the email 
cron script could be given a similar argument.

With these features, system-hosted calendars would become useful for 
the many people that just subscribe to various mailing lists, rather 
than just web-addicted fiends or people with mozilla or ical. I'm so 
excited about what's happening with php icalendar. ;-)

If no-one puts a thumbs down to the above ideas, or takes them on, I'll 
start work on them sometime around the 15th.

b.

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

[Jon C. T. <cal...@wa...>]

On Sunday, December 1, 2002, at 06:40  PM, Chad wrote:

> We've moved to just passing a serialized array for the popup 
> information,
> that way just one field can contain all the information.

With some browsers and servers, that limits the amount of text per 
description.

In all cases, that leads to unnecessary duplication (such as my example 
of ten times per page).

But I can happily wait for templates to fix these things locally.

Actually, one thing that would help tremendously right now would be to 
centralize the generation of these links into a function in 
draw_functions.php.  That way we can all determine how we create these 
popups on a site by site basis, all in one place.  Right now that same 
work is done in five different files.

> Hover events are cute but of no real practical use(IMHO).

I agree.  I probably wouldn't use them here, but keeping the door open 
seems worthwhile.