NYCPHP Meetup

[Brian O'Connor]

Actually, because when I created these websites with events, I was dealing
with an individual's events, and on the large scale, any one user most
likely won't have an overwhelming amount of events.  So each time their
calendar was loaded, I grabbed all their events, and looped through them
(with some filters, like if it never recurred, and it didn't happen during
that month, I didn't need to grab that).

In addition to my key/value approach that I described earlier, it was just a
huge if / else if block, and if anyone has any suggestions on how to improve
that, I'd be very happy to hear.  Basically, right now it goes through the
events one at a time checking each day for each event.  For instance, if an
event is to happen once every month on the 29th, it would have a key of 1,
and a value of 29, and then if the event had the start time of "yyyy-mm-29",
it would return true for that event on that day.

On 3/29/06, csnyder <chsnyder at gmail.com> wrote:
>
> On 3/29/06, Brian O'Connor <gatzby3jr at gmail.com> wrote:
> > The way I always handled occurance was to have two fields in the
> database, a
> > key (usually an integer), and a value, which I stored as a string.
> >
> > I then had a function which took an event and a day in, and checked the
> > events occurance key / value to see if it applied for that day, and
> returned
> > either true or false.
> >
> > I doubt this is the most efficient way, but it works for me.
>
>
> Let's say I want to render all of the events on a particular date:
> April 1, 2006, a Saturday. There is an event on January 18, 2003 (also
> a Saturday) which is set to recur every two weeks... which translates
> in this case to "odd Saturdays". Okay, I see how that would work.
>
> For any given day you generate a list of all the possible matches
> (April 1, 2006 is a Saturday, an odd Saturday, first Saturday, first
> of the month, etc), and then SELECT against those matches to find the
> events that apply.
>
> And multi-day events would just work, as long as you enforce a maximum
> duration, right? If events can last up to 5 days, you have to start
> your lookups 5 days before the month in question in order to capture
> recurring events that started before, but end during the month.
>
> To be truly useful you need to have an override mechanism -- one time
> events that mask out properties on a recurring event. We have a
> monthly meeting the recurs on 4th Tuesdays, but each instance of that
> event has a different "who" and "what". That seems like the easy part.
> A truly excellent implementation would even allow you to push or pull
> the start date, so that Cliff could reschedule the publication of his
> newsletter.
>
> You might also want an event log to track events that have actually
> happened, so that when a recurring event is updated to reflect a new
> reality, it doesn't rewrite history.
>
> John, your taxonomy idea is interesting (fetch events tagged
> "Wednesdays") and essentially the same as the "key/value" approach
> Brian described. If you're using a system that has robust tagging
> (like Ning) it might save some time.
>
>
> --
> Chris Snyder
> http://chxo.com/
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> New York PHP Conference and Expo 2006
> http://www.nyphpcon.com
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>



--
Brian O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060329/90c8ec8a/attachment.html>