Forum OpenACS Development: Meeting Scheduler over Calendar
I'm trying to build Meeting Scheduler over Calendar package and found many uncompleted and unconfortable things in Calendar.
I plan to add resource conflict resolving and scheduled audience notification for special types of events.
Do somebody maintains the Calendar?
I'm ready to join this group.
I also has a question realted to the cal_item_types.
Why item type is related to the calendar? It seems more reasonable to use same types for different calendars.
Calendar is in really bad shape. I fixed some bugs in it, but I really didn't see spending much time on the package given the number of basic problems involved.
Calendar is in extremely bad shape.
Among its problems are the fact that a cal_item is subtyped from an event and is a primary key. Thus insuring that you can't easily share events with multiple calendars.
The granularity is at the calendar level not the item level. This is plain wrong, and I am working on a fix for it.
Here is a scenario, suppose you want to use the calendar to do some scheduling of maintenance at offices. You don't have employees to do the work, but you hire contractors. So every contractor has their private calendar and the project has a calendar and each office needs their calendar. So you set up a project that is, for example, replace all alarm keypads at all the offices in the Southern Florida region.
Now, you have scheduled each office with a contractor to do this job. Since more than one contractor is working on the project we want the contractors to only see their jobs on their calendars. This rules out making the project calendar public. Also, we don't necessarily want the offices seeing other offices information.
So the options are:
- Create some seperate mapping tables and insert the cal_item_id (acs_event_id) into these tables as well as the cal_item. This allows us to at least use some of calendar, but not the calendar UI as it won't find the cal_item on that calender and it isn't public (group calendars won't work either, remember privacy).
- Insert the event into each parties calendar, thereby making sure that your data integrity will get hosed. Both options are not good.
One easy (though probably not ideal) solution is to add a new surrogate primary key to cal_events and take the primary key constraint off of cal_item_id. This would allow multiple calendars to map to the same event.
I haven't looked through all the code to see what ramifications that would have, but it is the simplest that I could think of to fix the existing calendar. A complete rewrite could probably find better solutions.
I will think about problems your mentioned about. And I'm ready to help in implemention of new version of the package.
I still playing with current version of the Calendar and need few extra days to get an exact pciture of what I like to change. Will come back to forum with new ideas soon.
At the moment I have suggestion about item_type. I think calendar_id may be removed from the cal_item_types table.
Different calendars may has events of the same type.
See this thread in which Ben summarizes some of the problems with the datamodel and in which someone describes how they poached then modified the datamodel for a Java project they were working on.
I think it would be nice to have the actual calendar content be a content (repository) type so one could register a template to it and control how the calendar event is displayed by the calendar package.
The project I allude to above solved issues by removing content item and adding a mapping table to map a calendar event to one or more calendars.
The existing calendar packages, sick as it is, functions well enough for many needs and while not bug-free is fairly stable. I'm inclined to think in terms of a datamodel rewrite resulting in a "new-calendar" package , i.e. to ignore the writing of scripts to upgrade from the old to new datamodel. I fear that trying to live with that constraint might hinder the design of a new, cleaner datamodel.
What do other folks think? Are some of the folks in this thread willing to work on redesigning the datamodel? I think a lot of the existing code - especially the widget and graphics code - could be poached without much effort once we have a decent datamodel.
I have a tarball of the old Ars Digita room reservation system if you're interested in looking at it, Denis.
I think we should start fresh for the reasons Don stated. Calendar does work, it just isn't worth trying to fix the problems it has. One problem I ran into is that the API requires a connection thread, this problem is impossible to remove with out a rewrite of most every page and proc.
I'm not sure a calendar should be tied to a package_id, because who wants to see different calendar content based on the package they are using? I want to see 'my' calendar, with everything on it
One other annoyance with the current calendar is that the markup used to be in .adp files (in 4.5). In 4.6 it move into library code. Nasty html hardcoded into library procedures!
Using the cr, could we design containers that would actually be things like a monthly/weekly/daily/list calendar which contains other cr items? Then the calendar package would be more flexable wouldn't it? Focusing more on a tcl api for use by other applications?
Whoever wants contact me and we can coordinate until we get official.
Also, Jerry Asher (theashergroup.com) has a problem set solution that seems to be nice (I had no luck getting logged in there).
As I see from discussions room reservation package should be what I actually need. Don Baccus also mentioned about it in his reply. I will try to port it to 4.6 and see how it possible to join with Calendar package.