I've made some changes to my logic, on displaying the calendars.
I've been looking a large number of calendars out there, many CPAN modules, and some ideas have merit. It's just odd no one has put something together in all this time (I guess like DMOZ/RDF stuff).
The change in this case, (and I might keep both sorts of functionality in) is to look at how the calendar/day was built.
It's less expensive, from a database call point of view, to call all events within a date range, at one time, then build the calendar day-by-day by reading through the block of returned results. This logic is similar to the group-by-date logic on the New page. The calendar is then built reading through this sorted hash of sorted hash values, inserting a "blank" page where no values are found.
It's a tad less "expensive" to handle the no-events exception in the code, rather than execute a build_day routine.
But, in order to allow dates/days and a days of events to be used on other pages, it "pays" to put in the logic (develop the system) to build-by-day so the "core" logic of the system uses "Events" as objects (the "stored" object), and assembles them into "days" which are then assembled into the calendar.
Each portion is template driven, and hopefully, it will be easy to pass in a template from any point to override the default set, for display on different pages, or inclusion into a "Today" type listing.
Also, I'm toying with storing "recurring" events in a different table, so it would mean two database calls, but it would make processing easier:
1) gather all fixed-date events
2) request all recurring events
3) sort recurring events into the event-hash based on the date-range parameters.
The problem with a recurring event, is it has no "date" parameters, so they have to be assigned when the event is requested. "Tuesdays", "3rd Monday", etc are not "dates".
this gets complex really, really fast, with all sorts of "exceptions", so it's still for a later release,
Again -- any suggestions or comments....
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I've been looking a large number of calendars out there, many CPAN modules, and some ideas have merit. It's just odd no one has put something together in all this time (I guess like DMOZ/RDF stuff).
The change in this case, (and I might keep both sorts of functionality in) is to look at how the calendar/day was built.
It's less expensive, from a database call point of view, to call all events within a date range, at one time, then build the calendar day-by-day by reading through the block of returned results. This logic is similar to the group-by-date logic on the New page. The calendar is then built reading through this sorted hash of sorted hash values, inserting a "blank" page where no values are found.
It's a tad less "expensive" to handle the no-events exception in the code, rather than execute a build_day routine.
But, in order to allow dates/days and a days of events to be used on other pages, it "pays" to put in the logic (develop the system) to build-by-day so the "core" logic of the system uses "Events" as objects (the "stored" object), and assembles them into "days" which are then assembled into the calendar.
Each portion is template driven, and hopefully, it will be easy to pass in a template from any point to override the default set, for display on different pages, or inclusion into a "Today" type listing.
Also, I'm toying with storing "recurring" events in a different table, so it would mean two database calls, but it would make processing easier:
1) gather all fixed-date events
2) request all recurring events
3) sort recurring events into the event-hash based on the date-range parameters.
The problem with a recurring event, is it has no "date" parameters, so they have to be assigned when the event is requested. "Tuesdays", "3rd Monday", etc are not "dates".
this gets complex really, really fast, with all sorts of "exceptions", so it's still for a later release,
Again -- any suggestions or comments....
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.